How often should security logs be reviewed?

Security logs are one of the most important components of any security program. They provide insight into how well your security program is working, and they serve as a valuable source of intelligence for incident response. However, they are not perfect; they can contain false positives and false negatives. As a result, they need to be reviewed regularly to ensure they are providing accurate information.

There are two main reasons why security log reviews are necessary. First, they allow you to identify problems before they become serious incidents. Second, they allow you to determine whether your current security measures are effective.

When reviewing logs, look for three things:

1. Incidents – These are events that indicate something has gone wrong. For example, a firewall blocking access to a website, or a virus scanning software alerting you to a malware infection.

2. False Positives – These are alerts that don’t represent anything actually happening. For example, a virus scanner warning you about a file that was downloaded from the Internet without any infection identified.

3. False Negatives – These are alerts that do represent something actually happening, but were missed because of a flaw in the system. For example, a server being accessed remotely, but no alarms raised.

Reviewing logs every day is recommended. If you review logs daily, you will catch issues sooner and prevent them from becoming major incidents. This should be done on a rotating basis by the security team to prevent fatigue from diminishing the quality of the work, or via automated methods to reduce fatigue.

Peer reviewing logs weekly is also recommended. It allows you to spot trends and anomalies that might otherwise go unnoticed by a single reviewer. It also gives a second set of eyes on the logs, and helps guard against fatigue or bias-based errors.

Finally, aggregated trend-based monthly reviews are recommended. This gives you a chance to look back and see if there have been any changes to your environment that could affect your security posture or represent anomalies. This is a good place to review items like logged events per day, per system, trends on specific log events and the like. Anomalies should be investigated. Often times, this level of log review is great for spotting changes to the environment or threat intelligence.

If you want to learn more about how to conduct log reviews effectively, reach out to us at info@microsolved.com. We’re happy to help!

How long should security logs be kept?

Security logs are a great source of information for incident response, forensics, and compliance purposes. However, log retention policies vary widely among organizations. Some keep logs indefinitely; others only retain them for a certain period of time. Logging practices can impact how much useful information is available after a compromise has occurred.

In general, the longer logs are retained, the better. But, there are several factors to consider when determining how long to keep logs. These include:

• What type of system is being monitored?

• Is the system mission-critical?

• Are there any legal requirements regarding retention of logs?

• Does the company have a policy regarding retention of logs? If so, does it match industry standards?

• How often do incidents occur?

• How many employees are affected by each incident?

• How many incidents are reported?

• How many hours per day are logs collected?

• How many days per week are logs collected?

It is important to understand the business needs before deciding on a retention policy. For example, if a company has a policy of retaining logs for 90 days, then it is reasonable to assume that 90 days is sufficient for the majority of situations. However, if a company has no retention policy, then it is possible that the logs could be lost forever.

Logs are one of the most valuable sources of information during an investigation. It is important to ensure that the right people have access to the logs and that they are stored securely. In addition, it is important to know how long logs need to be kept.

MicroSolved provides a number of services related to logging and monitoring. We can help you create logging policies and practices, as well as design log monitoring solutions. Drop us a line at info@microsolved.com if you’d like to discuss logging and logging solutions.

What should be in a security log?

Logging is one of the most important aspects of any security program. It provides a record of events that occur within your environment, which allows you to understand how your systems are being used and what vulnerabilities exist. Logging helps you identify issues before they become problems, and it gives you insight into what happened after the fact.

There are many different types of logs, each with its own purpose. Some logs are designed to provide information about system activity, while others are intended to capture information about network traffic or application behavior. There are also different levels of logging, ranging from basic records of actions taken by applications, to detailed records of every event that occurs during the execution of an application.

In general, the more detail you can include in your logs, the better. For instance, if you’re looking for evidence of a compromise, you’ll need to look for signs of unauthorized access to your systems. A log entry that includes details about the IP addresses involved in the request will allow you to correlate the requests with the users making them. Similarly, if you’re trying to determine whether a particular file was accessed by someone else, you’ll need to examine the contents of the log entries associated with that file.

As you consider what type of logs to create, keep in mind that not all logs are created equal. In addition, not all logs are equally useful. For example, a log of HTTP requests might be helpful in determining whether a web server has been compromised, but it won’t tell you much about the nature of the threat. On the other hand, a log of failed login attempts could indicate that a malicious actor is attempting to gain access to your systems.

The best way to decide what kind of logs to create is to think about the specific threats you face and the kinds of information you want to collect. If you’re concerned about a particular type of threat, such as phishing emails, then you’ll probably want to track email messages sent to your domain. If you’re worried about malware infections, you’ll likely want to monitor the activities of your users’ computers.

In general, as a minimum, make sure the elements of the common logging format are included and build from there. If you need assistance with log design or help determining and implementing a logging strategy, drop us a line at info@microsolved.com. We’re happy to help! 

Automating SSL Certificate Management with Certbot and Let’s Encrypt

As we posted previously, following best practices for SSL certificate management is critical to properly secure your site. In that post, we discussed automating certificate management as a best practice. This post is an example of how to do just that.
 
To do so, we will use the highly-trusted free certificate provider Let’s Encrypt. We will also leverage the free certificate automation tool Certbot.
 

Installing Certbot

Installing Certbot is pretty easy, overall, but you do need to be comfortable with the command line and generally know how to configure your chosen web server. That said, if you check out the Certbot site, you will find a dropdown menu that will let you pick your chosen web server and operating system. Once you make your selections, simply follow the on-screen step-by-step instructions. In our testing, we found them to be complete and intuitive.
 

That’s It!

Following the on-screen instructions will have:

  • Certbot installed
  • Configure your web server for the certificate
  • Generate, get and install the certificate
  • Implement automatic renewals of the certificate to prevent expiration

You can literally go from a basic website to fully implemented and automated SSL in a matter of moments. Plenty of support is available from EFF for Certbot, or via Let’s Encrypt. In our testing, we ran into no issues and the implementation completed successfully each time.

Give it a shot! This might be one of the easiest and most effective security controls to automate. Together, Certbot and Let’s Encrypt can create a no-cost cryptography solution for your web sites in a very short amount of time.

SSL Certificate High-Level Best Practices

SSL certificates are an essential part of online security. They protect websites against hackers who try to steal information such as credit card numbers and passwords. In addition, they ensure that customers trust the site and its content.

Almost 50% of the top one million websites use HTTPS by default (they redirect inquiries of HTTP pages to URLs with HTTPS). (comodosslstore.com)As such, even pages that don’t deal with confidential data are being deployed using SSL. The underlying certificates to power the encryption are available from a variety of commercial providers, and even the pro-bono resource https://letsencrypt.org. No matter where you get your certificate from, here are a few resources for high-level best practices.

Trust Your Certificate Provider

Since certificates provide the basis for the cryptography for your site, their source is important. You can find a trustworthy list of providers for certificates here. https://www.techradar.com/news/best-ssl-certificate-provider. Beware of commercial providers not found on this list, as some of them may be sketchy at best, or dangerous at worst. Remember, the Let’s Encrypt project above is also highly trusted, even though they are not a commercial firm.

Manage Versions and Algorithms

Make sure you disable SSL and TLS 1.0 on the server. That version has known vulnerabilities. If possible, and there are no impacts on your users, consider removing 1.1 and 1.2 as well. 1.3 fixes a lot of the known issues with the protocol and supports only the known secure algorithms.

In cryptography, cipher suites play an important part in securing connections by enabling encryption at different levels. You shouldn’t be using an old version of a cryptographic protocol if there’s a newer one available; otherwise, you may put your site’s security at risk. Using secure cipher suites that support 128-bit (or more) encryption is crucial for securing sensitive client communications.

Diffie Hellman Key Exchange has been shown to be vulnerable when used for weaker keys; however, there is no known attack against stronger keys such as 2048-bits. Make sure you use the strongest settings possible for your server.

Manage and Maintain Certificate Expiration

As of Sept. 1, 2020, Apple’s Safari browser will no longer trust certificates with validity periods longer than 398 days, and other browsers are likely to follow suit. Reducing validity periods reduces the time period in which compromised or bogus certificates can be exploited. As such, any certificates using retired encryption algorithms or protocols will need to be replaced sooner. (searchsecurity.techtarget.com)

Maintain a spreadsheet or database of your certificate expiration dates for each relevant site. Make sure to check it frequently for expiring certificates to avoid user issues and browser error messages. Even better is to use an application or certificate management platform that alerts you in plenty of time to upcoming certificate expirations – thus, you can plan accordingly. Best of all, if possible, embrace tools and frameworks for automating certificate management and rotation – that makes sure that you are less likely to have expiration issues. Most popular web frameworks now have tools and plugins available to perform this for you.

Protect Your Certificates and Private Keys

Remember that your certificate is not only a basis for cryptography, but is also a source of identification and reputation. As such, you need to make sure that all certificates are stored properly, securely and in trusted locations. Make sure that web users can’t access the private certificate files, and that you have adequate back up and restore processes in place.

Make sure that you also protect the private keys used in certificate generation. Generate them offline, if possible, protect them with strong passwords and store them in a secure location. Generate a new private key for each certificate and each renewal cycle.

Revoke your certificate or keys as quickly as possible if you believe they have been compromised.

Following these best practices will go a long way to making your SSL certificate processes safer and more effective. Doing so protects your users, your reputation and your web sites. Make sure you check back with your certificate provider often, and follow any additional practices they suggest.

 

 

 

 

Tips For Recognizing a Phishing Email

Below are some common tips for helping to identify phishing emails at work or at home. The same rules apply.

Most Phishing Emails Originate at Common Domains

The first way to recognize a phishing email is that most originate from a public email domain.

There are few legitimate organizations that will send emails from an address that ends in @gmail.com, not even Google does this.

To check an organization’s name, type it into a search engine.Most of the time, organizations have their own email and company accounts and don’t need to use an @gmail.com address.

Check the Spelling of the Domain, Carefully!

There is another clue hidden in domain names that shows a strong indication of the scam.

Anyone can purchase a domain name from a website. There are many ways to create addresses that are easily confused with the official domain of a brand or company. The most common ways include slight mis-spellings of the domain name, or by changing one character to a number or letter that resembles the original. Be extra vigilant for these types of spoofing attempts.

Grammer and Spelling Counts

It’s often possible to tell if an email is a scam if it has poor spelling and grammar. Odd terminology or phrasing is also a clue. For example, your bank is unlikely to misspell the word checking or account, and they would not usually call an ATM machine a “cash machine”. These clues can be subtle, but often indicate that an email is not what it claims to be.

Beware of Potentially Malicious Links and Attachments

Sometimes, the wording in an email might be right, but the links send you to somewhere unexpected on the web. You can check this out in most clients and browsers by simply hovering the mouse cursor over the link without clicking on it. That’s an easy way to know where the link is taking you, and note that it might be somewhere other than what the links says it is.

You should always beware of attachments in emails. Everyone knows that malicious code and ransomware can be hiding in documents, spreadsheets and such, but they can also appear to be image files, presentations, PDFs and most types of documents. If you aren’t expecting the attachment, delete it!

Too Good To Be True

Lastly, if the offer is too good to be true, it probably is. Few people have won the lottery and been notified by email. Even less have been chosen for random gifts or to receive inheritance from Kings and Queens. Don’t be gullible, and remember, scammers are out there, and they want to trick you.

What to Do When You Spot a Phish

The first thing is to delete the email and attachments. If it is a work email, you should also notify the security team that you received it. They can investigate, as needed. In some firms, they may want you to forward it to a specific email address for the security team, but most security teams can recover the email information even if you delete it. Follow their instructions.

At home, just delete the email and tell your family and friends about it. The more folks are aware of what’s going around, the less likely there are to fall into the trap.

More Information

We’d love to discuss phishing attacks, emerging threats or common security controls for organizations. Reach out to info@microsolved.com or give us a call at 614-351-1237 for help.

Thanks for your attention, and until next time, stay safe out there.

 

 

Beware of Increasing Attacker Automation

Attacker tools and workflows are getting more and more automated. They are able to quickly integrate a variety of attack techniques and targets to automate wider-scale compromises and exploitation. This increase in automated capabilities applies to all phases of the attacker methodologies.

For example, modern attacker and bot-net tools can integrate stolen credentials use (“credential stuffing”) into a wider variety of approaches. They can automate the work of the attackers when they find a successful login. They can also try those credentials against a wider set of targets, including various e-commerce and popular social media sites. Essentially, this makes exploitation of stolen credentials significantly easier for an attacker, and potentially, more damaging to the victims whose credentials have leaked.

Stolen credentials and the tools to use them are evolving rapidly, and a significant amount of innovation and evolution are expected in these tool sets over the next year to 18 months. Entire platforms given to user emulation and capable of doing en masse correlation of stolen user data across breach sets are what I expect to see in the next year or so. When these tools emerge, new economies of scale for online identity theft will quickly emerge, raising both awareness and criticality of the problem.

Folks at various security organizations, including Akamai, are also tracking the problem. (https://portswigger.net/daily-swig/behind-the-botnet-akamais-tony-lauro-on-tackling-real-world-credential-stuffing-attacks) Robust defenses against these automated platforms are going to be needed, and it will place significant stress on organizations who lack mature security programs with advanced visibility and analytics capabilities.

If you’d like some assistance preparing for these types of automated attacks or would like to discuss the potential impacts they may have on your organization, feel free to get in touch (https://microsolved.com/contact) or give us a call at 614-351-1237.

Preparing for the End of SMS Authentication

Over the last several years, wealth management/asset management firms have been integrating their systems with banking, trading and other financial platforms. One of the largest challenges wealth management firms face, from a technology standpoint, is managing multi-factor authentication when connecting to the accounts of their clients. In the coming year to eighteen months, this is likely to get even more challenging as SMS-based authentication is phased out. 

Today, many financial web sites, applications and phone apps require the use of SMS one-time security verification codes to be sent via text to the user. This usually happens once the user has entered their login and password to the system, after which it triggers the credential to be sent to their mobile phone number on record. The user then inputs this code into a form on the system and it is verified, and if correct, allows the user to proceed to access the application. This is called two factor authentication/multi-factor authentication (“MFA”) and is one of the most common mechanisms for performing this type of user authorization.

The problem with this mechanism for regulating sign ins to applications is that the method of sending the code is insecure. Attackers have a variety of means of intercepting SMS text messages and thus defeating this type of authentication. Just do some quick Google searches and you’ll find plenty of examples of this attack being successful. You’ll also find regulatory guidance about ending SMS authentication from a variety of sources like NIST and various financial regulators around the world. 

The likely successor to SMS text message authentication is the authenticator app on user mobile devices and smartphones. These authenticator apps reside in encrypted storage on the user’s phone and when prompted, provide a one-time password (“OTP”) just like the code sent in the text message. The difference is, through a variety of cryptographic techniques, once the application is setup and  the settings configured, it doesn’t need to communicate with the financial platform, and thus is significantly more difficult for attackers to compromise. Indeed, they must actually have the user’s device, or at the very least, access to the data that resides on it. This greatly reduces the risk of interception and mis-use of the codes in question, and increases the security of the user’s account with the financial institution.

This presents a significant problem, and opportunity, for wealth management firms. Transitioning their business processes from integrating with SMS-based authentication to authenticator apps can be a challenge on the technical level. Updates to the user interaction processes, for those firms that handle it manually, usually by calling the user and asking for the code, are also going to be needed. It is especially important, for these manual interactions, that some passphrase or the like is used, as banks, trading platforms and other financial institutions will be training their users to NEVER provide an authenticator app secret to anyone over the phone. Attackers leveraging social engineering are going to be the most prevalent form of danger to this authentication model, so wealth management firms must create controls to help assure their clients that they are who they say they are and train them to resist attackers pretending to be the wealth management firm. 

Technical and manual implementations of this form of authentication will prove to be an ongoing challenge for wealth management firms. We are already working with a variety of our clients, helping them update their processes, policies and controls for these changes. If your organization has been traditionally using SMS message authentication with your own clients, there is even more impetus to get moving on changes to your own processes. 

Let us know if we can be of service. You can reach out and have a no stress, no hassle discussion with our team by completing this web form. You can also give us a call anytime at 614-351-1237. We’d love to help! 

Getting ROI with ClawBack, our Data Leak Detection Platform

So, by now, you have likely heard about MicroSolved’s ClawBack™ data leakage detection engine. We launched it back in October of 2019, and it has been very successful among many of our clients that have in-house development teams. They are using it heavily to identify leaks of source code that could expose their intellectual property or cause a data breach at the application level.

While source code leaks remain a signficant concern, it is really only the beginning of how to take advantage of ClawBack. I’m going to discuss a few additional ways to get extreme return on investment with ClawBack’s capabilities, even if you don’t have in-house developers.

One of the most valuable solutions that you can create with ClawBack is to identify leaked credentials (user names and passwords). Hackers and cyber-criminals love to use stolen passwords for credential-stuffing attacks. ClawBack can give you a heads up when stolen credentials show up on the common pastebin sites or get leaked inadvertantly through a variety of common ways. Knowing about stolen credentials makes sense and gives you a chance to change them before they can be used against you. 

We’ve also talked a lot about sensitive data contained in device configurations. Many potentially sensitive details are often in configuration files that end up getting posted in support forums, as parts of resumes or even in GITHub repositories. A variety of identifiable information is often found in these files and evidence suggests that attackers, hackers and cybercriminals have developed several techniques for exploiting them. Our data leak detection platform specializes in hunting down these leaks, which are often missed by most traditional data loss prevention/data leakage prevention (DLP)/data protection tools. With ClawBack watching for configurations exposures, you’ve got a great return on investment.

But, what about other types of data theft? Many clients have gotten clever with adding watermarks, unique identity theft controls, specific security measures and honing in on techniques to watch for leaked API keys (especially by customers and business partners). These techniques have had high payoffs in finding compromised data and other exposures, often in near real time. Clients use this information to declare security incidents, issue take down orders for data leaks and prevent social engineering attackers from making use of leaked data. It often becomes a key part of their intrusion detection and threat intelligence processes, and can be a key differentiator in being able to track down and avoid suspicious activity.

ClawBack is a powerful SaaS Platform to help organizations reduce data leaks, minimize reputational risk, discover unusual and often unintentional insider threats and help prevent unauthorized access stemming from exposed data. To learn more about it, check out https://microsolved.com/clawback today.

Saved By Ransomware Presentation Now Available

I recently spoke at ISSA Charlotte, and had a great crowd via Zoom. 

Here is the presentation deck and MP3 of the event. In it, I shared a story about an incident I worked around the start of Covid, where a client was literally saved from significant data breach and lateral spread from a simple compromise. What saved them, you might ask? Ransomware. 

That’s right. In this case, ransomware rescued the customer organization from significant damage and a potential loss of human life. 

Check out the story. I think you’ll find it very interesting. 

Let me know if you have questions – hit me up the social networks as @lbhuston.

Thanks for reading and listening! 

Deck: https://media.microsolved.com/SavedByRansomware.pdf

MP3: https://media.microsolved.com/SavedByRansomware.mp3

PS – I miss telling you folks stories, in person, so I hope you enjoy this virtual format as much as I did creating it!