Supply Chain Security Insights

Supply chain attacks are one of the most common cyber threats faced by organizations. They are costly and disruptive, often resulting in lost revenue and customer trust.

In this article, we’ll discuss five insights about supply chain attacks that all supply chain management and information security teams should be aware of.

#1. Supply Chains Can Be Vulnerable

Supply chains are complex networks of companies, suppliers, customers, and partners that provide goods and services to each other.

They include manufacturers, distributors, retailers, service providers, logistics providers, and others.

These entities may interact directly or indirectly via intermediaries such as banks, insurance companies, payment processors, freight forwarders, customs brokers, etc.

Supply chains are vulnerable to attack because they involve multiple parties and interactions between them. Each organization in the chain will have its own risk profile, security posture, and business model. This creates a complex environment for security risks. Attackers can target any part of the supply chain, and often focus on the weakest link, including manufacturing facilities, distribution centers, warehouses, transportation hubs, retail stores, etc.

Attackers can disrupt operations, steal intellectual property, damage reputation, and cause losses in revenue and profits.

#2. Supply Chain Security Must Include All Stakeholders

Supply chain security involves protecting against threats across the entire value stream. This means securing data, processes, systems, physical assets, personnel, and technology.

It also requires integrating security practices and technologies across the entire organization.

This includes ensuring that information sharing occurs among stakeholders, that employees understand their roles and responsibilities, and that policies and procedures are followed.

Security professionals should collaborate closely with executives, managers, and staff members to ensure that everyone understands the importance of security and has ownership over its implementation.

#3. Supply Chain Security Requires Ongoing Monitoring and Maintenance

Supply chain security requires ongoing monitoring and maintenance.

An effective approach is to continuously monitor the status of key indicators, assess risks, identify vulnerabilities, and implement countermeasures.

For example, an attacker could attempt to compromise sensitive data stored in databases, websites, mobile apps, and other locations.

To prevent these incidents, security teams should regularly review logs, audit reports, and other intelligence sources to detect suspicious activity.

They should also perform penetration tests, vulnerability scans, and other assessments to uncover potential weaknesses.

#4. Supply Chain Security Requires Collaboration Across Organizations

A single department cannot manage supply chain security within an organization.

Instead, it requires collaboration across departments and functional areas, including IT, finance, procurement, human resources, legal, marketing, sales, and others.

Each stakeholder must be responsible for maintaining security, understanding what constitutes acceptable behavior, and implementing appropriate controls.

Collaborating across organizational boundaries helps avoid silos of knowledge and expertise that can lead to gaps in security awareness and training.

#5. Supply Chain Security Is Critical to Organizational Success

Organizations that fail to protect their supply chains face significant financial penalties.

A recent study found that supply chain breaches cost United States businesses $6 trillion annually.

That’s equivalent to nearly 10% of the annual global GDP.

Supply chain attacks can result in lost revenues, damaged reputations, and increased costs.

Companies that invest in supply chain security can significantly improve operational efficiency, productivity, profitability, and brand image.

How to Rotate Your SSH Keys

SSH keys are used to secure access to and authenticate authorized users to remote servers. They are stored locally on the client machine and are encrypted using public-key cryptography. These keys are used to encrypt communications between the client and server and provide secure remote access.

When you log into a remote machine, you must provide a valid private key to decrypt the traffic. As long as the private key remains secret, only you can access the server. However, if someone obtains your private key, they can impersonate you on the network.

SSH key rotation helps prevent this type of unauthorized access. It reduces the risk that someone has access to your private key, and helps prevent malicious users from being able to impersonate you on your network.

Most security policies and best practices call for rotating your key files on a periodic basis, ranging from yearly to quarterly, depending on the sensitivity of the data on the system. Such policies go a long way to ensuring the security of authentication credentials and the authentication process for sensitive machines.

There are two ways to rotate your keys: manually, and automatically.

Manually

To manually perform key rotation, you need to generate a new pair of keys. Each time you do this, you create a new key pair. You then upload the public key file to the server you wish to connect to. Once uploaded, the server uses the public key to verify that you are who you say you are.

Automatically

An alternative approach is to use automatic key rotation. With automatic rotation, you don’t need to generate a new key pair each time you change your password. Instead, you simply update the permissions on your existing key file.

The following steps show how to configure automatic rotation.

1. Generate a new keypair

2. Upload the public key to the remote server

3. Configure the remote server to use the new keypair

4. Update the permissions on the old keypair file

5. Delete the old keypair

6. Logout from the remote server

More Information

On Linux systems, use the “man” command to learn more about the following:

    • ssh-keygen command
    • ssh-public-key command
    • upload-ssh-public-key command

The examples should provide options for command parameters and sample command output for your operating system.

For more information about the SSH protocol, you can review the Wikipedia article here.

 

A Cynefin Risk Management Use Case

Lately, I have been working on using the Cynefin framework to help a client with supply chain risk management. I’m not going to dig into the specifics here, but I wanted to share a quick workflow that we used during this process that has been very useful for us.

Risk Matrix

First, we built a risk matrix for supply chain risk. Basically, there are a number of these available via the various search engines. We took some of the most common ones and tore them down to commonalities, then built them into our matrix. We turned this into a simple spreadsheet.

Heat Mapping

Next, once we had our risk matrix, we did an exercise where we heat mapped the various risks, scoring them high/medium/low subjectively. This gave us an excellent tool to monitor our situation and communicate it with our stakeholders.

Applying Cynefin

Next, we mapped all of the high risks into the cynefin framework by researching the present state of each, whether best practices were available and relevant, being developed, or still in the experimental stage. This gave us a good idea of which problems we could simply focus on using known techniques and skills against, which ones we needed to take existing decent practices and optimize them, and which problems we needed to experiment with solutions for.

Sharing and Feedback

Overall, the exercise took around an hour to complete once we compiled the basic templates and completed the risk matrix research. For those of you facing complex risk management problems, this workflow might assist. Let me know on social media (@lbhuston) if it provides any help or if you have suggestions and feedback. Thanks for reading!

3 Common Challenges Implementing Multi-Factor Authentication

Multi-factor authentication is becoming increasingly popular among businesses and consumers alike.

However, many organizations struggle to implement the technology successfully.

Here are three challenges organizations face when implementing multi-factor authentication.

1. Lack of Awareness

Many organizations don’t understand what multi-factor authentication is or why they should use it.

They think it’s too complicated, expensive, or unnecessary.

This misconception leads to a lack of awareness about the security risks posed by weak passwords and phishing attacks.

2. Security Concerns

Some organizations believe that multi-factor authentication adds complexity and cost to their IT infrastructure.

But, in reality, multi-factor authentication doesn’t add much overhead.

Instead, it provides additional layers of protection against cyberattacks.

3. Complexity

Organizations sometimes find it difficult to integrate multi-factor authentication into their existing systems.

For example, they might have to replace old software or change user interfaces.

Some Potential Solution Ideas

If you’re struggling to implement multi-factor authentication, here are some tips to help you overcome these challenges.

1. Educate Employees About Multi-Factor Authentication

Educating employees about multi-factor authentication helps them understand its importance.

Make sure employees know that using multi-factor authentication reduces the likelihood of fraud and improves overall security.

2. Use Technology That Works For You

Multi-factor authentication tools are becoming more popular by the day. Many low-cost, or even free, solutions exist from vendors like Microsoft, DUOand others.

Look for solutions that have easy integration with your existing business infrastructure and systems.

3. Work With A Partner

A partner who has experience implementing multi-factor authentication can be helpful.

An experienced partner can provide guidance and support throughout the implementation process.

4. Make Sure The Solution Is Right For You

Before choosing a solution, make sure it meets your organization’s needs.

As always, if we can be of assistance, drop us a line to info@microsolved.com. We’d be happy to help!

3 Essential Raspberry Pi Hardening Steps

Raspberry Pi hardening is essential for securing your device against attacks.

Here are three essential Raspberry Pi hardening steps:

1. Disable SSH If You Don’t Need It

Disable SSH access to your Raspberry Pi using the following command:

sudo raspi-config

Choose “Advanced Options” and then choose “No ssh”.

2. Change Your Password

Change your password to something secure. You can use the following command:

passwd

3. Update Raspbian

Update your Raspberry Pi’s operating system to the latest version available. This ensures that your device is up to date with security patches and bug fixes.

To update your Raspberry Pi, follow these instructions:

sudo apt-get update

sudo apt-get upgrade

In summary, hardening your device by following these steps will help you protect your Pi from attacks. Making these three basic steps a part of every Pi install you do will go a long way to giving you a safer, more dependable, and more private experience.

 

 

How Does an IT Audit Differ from a Security Assessment?

One of the most common questions that I get asked is about the differences between an IT Audit and a Security Assessment. Hopefully, this quick overview helps to remove some of the confusion around these terms, which should not be used interchangeably.

What Is A Security Assessment?

A Security Assessment is a focused, proactive evaluation of an organization’s cybersecurity landscape that identifies potential risks and opportunities for improvement. The objective of conducting a Security Assessment is to provide an overview of an organization’s current state in terms of its cybersecurity posture. To do this, the currently implemented controls and systems are tested for resilience against common vulnerabilities and forms of attack.

Security assessments may, or may not, include penetration tests. However, they should always check for potential vulnerabilities. These reviews are best conducted by an independent third party.

What Is an IT Audit?

An IT Audit is a comprehensive review of your organization’s information technology (IT) infrastructure. It provides a detailed analysis of how well you are managing your IT resources, including hardware, software, networks, applications, policies, procedures, and controls.

It compares your current state of operations against a prescribed set of standards, controls, or requirements. These types of reviews are often conducted by an internal audit or an internal team, though many smaller firms use external consultants to complete them, as well.

What’s the Difference?

The difference between an IT Audit and a Security Assessment is one of scope. An IT Audit will typically focus on a single area or set of areas while a Security Assessment may cover multiple areas. For example, an IT Audit may include an examination of the organization’s capabilities to comply with a specific standard, for example, HIPAA, while a security assessment would test the cyber-security controls’ around your HIPAA data for effectiveness against common forms of attack.

In the end, an IT Audit is useful for getting a high-level overview of the gap between a required set of controls or standards, while a Security Assessment provides specific insights into how well the controls you have in place are protecting you and your assets.

What to Do with the Data

Once you have the insights provided by these engagements, you can easily use the data to update your security policies, implement additional internal controls to create an acceptable level of risks, revise your standard operating procedures or increase your network security and application-level protection.

Often, how the results of these engagements are used can be a major difference between the maturity level of your cybersecurity program. These processes should be used on at least a yearly basis for small firms, and on an ongoing basis for larger, more mature firms. Doing so will greatly improve your organizational security posture over time.

For more information on these types of engagements, or to discuss either an IT Audit or a Security Assessment, please get in touch with MicroSolved (info@microsolved.com or 614-351-1237). We would love to put our nearly 30 years of experience to work for you!

 

 

Basic Logging Advice

Logging and monitoring are two important aspects of any security program. Without logging, we cannot understand how our systems operate, and without monitoring, we cannot detect anomalies and issues before they become problems.

There are many different types of logs available to us today. Some are generated automatically, while others require manual intervention. For instance, network traffic is usually logged automatically. However, application logs are not. We may need to manually create these logs.

Application logs provide valuable information about what happened during the execution of an application. They can show us which parts of the application were executed, what resources were used, and what was returned. Application logs are often stored in databases, allowing us to query them later.

Network logs are also useful. They allow us to see what packets were sent and received, and what responses were made. 

System logs are another type of log that we should consider. System logs record events such as system startup, shutdown, reboots, etc. They are generally stored in files, but can also be recorded in databases.

While logs are very helpful, they do have their limitations:

  • First, logs are only as good as the people who generate them. If  something doesn’t save a log, then we likely don’t know what happened. We might be able to get that from some other log, but having multiple layers of logs around an event is often useful.
  • Second, logs are static. Once created, they should remain unchanged. Hashing logs, storing them on read only file systems and other forms of log controls are highly suggested.
  • Third, logs are not always accurate. Sometimes, logs contain false positives, meaning that something appears to be happening when actually nothing is. False negatives are also possible, meaning we don’t alert on something we should have. Logs are a part of detection solution, not the sole basis of one.
  • Fourth, logs are not always actionable. That means that we can’t easily tell from a log whether something bad has occurred or if it is just noise. This is where log familiarity and anomaly detection comes in. Sometimes reviewing logs in aggregate and looking for trends is more helpful than individual line by line analysis. The answer may be in looking for haystacks instead of needles…
  • Finally, logs are not always timely. They might be created after the fact, and therefore won’t help us identify a problem until much later. While good log analysis can help create proactive security through threat intelligence, they are more powerful when analyzing events that have happened or as sources for forensic data.

Keep all of these things in mind when considering logging tools, designing monitoring techniques or building logs for your systems and applications.

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!