Tag Archives: end user focused

Seek Out and Remove End-Of-Life Components

Posted on by
Reply

Just a quick reminder, at some point during each quarter, it is a good idea to enact a process to seek out and remove any end-of-life products in your environment. This is not only a best practice but a significant risk reduction measure as well. Make it an ongoing periodic process, and you’ve got a powerful weapon against threats and emerging issues stemming from end-of-life hardware, firmware, and software in your networks.

How to Search for End-Of-Life Products In Your Environment

The first step is to identify the devices, applications, and firmware that are no longer supported by their vendors. You can do this manually or with a tool. The next step is to determine which of those devices have been deployed in your network. Once you know where they are, you need to find them. There are several ways to search for these devices:

Use Network Inventory Tools

Network inventory tools such as Nmap and Nessus will allow you to scan your entire network to locate all of the devices on your network. These tools will also tell you what operating systems and versions of software/firmware are running on the device. If you’re using a vendor-specific tool, you’ll be able to see if there are any known vulnerabilities associated with the product in many cases.

Talk to Device and Application Owners

If you don’t already have a relationship with the owners of the devices and applications, then you should start building one now. It’s important to get to know the people who own the devices and applications so that you can ask questions about how they use the devices and applications. You may even want to consider getting an end-of-life security policy together for the organization so that you can make sure everyone understands the risks of end-of-life components.

Once you have discussed the issues with the owner, remove the component if possible. Otherwise, add it to a list of components to look for workarounds or replacements. Many organizations that can’t manage to replace an end-of-life component either place it in a low trust network zone, front-end it with firewalls or ACLs, and increase monitoring and detection of the assets involved. Of course, the component should be reviewed quarterly until it can be removed from service.

Doing this process every quarter will increase your networks’ overall stability and trust worthiness, plus reduce risk and management headaches. It’s well worth your time and an effective part of an overall risk management strategy.

How to Rotate Your SSH Keys

Posted on by
Reply

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.

 

WARNING: Migrate Windows Server 2003 Immediately

Posted on by
Reply

Believe it or not, we still get queries from a few utility companies that have operational processes locked on Windows Server 2003 as a platform. Most of the time, these are legacy applications associated with some form of ICS device or data management system that they have not been able to afford to replace.

Windows 2003 Server end-of-life searches are still among the most popular searches on our StateOfSecurity.com blog, receiving more than 200 queries most months. Keep in mind, this is an operating system that patches haven’t been released for since 2015. According to Spiceworks, an online community for IT professionals, the Windows 2003 Server operating system still enjoys a market share of 17.9%, though we could not validate the time frames of their claim.

But, just in the last year or so, we have seen it alive and well in natural gas, energy and the communications infrastructures, both foreign and domestic. So, we know it is still out there, and still being used in seemingly essential roles.

I’m not going to lecture you about using a system that is unmatched for 5 years. That’s just common sense. Instead, what I am going to do is make three quick suggestions for those of you who can’t get rid of this zombie OS. Here they are:

1. Install a firewall or other filtering device between the legacy system and the rest of your environment. This firewall should reduce the network traffic allowed to the system down to only specifically required ports and source addresses. It should also restrict all unneeded outbound traffic from the device to anything else in the network or the world. The device should be monitored for anomalies and security IOCs.

2. If the hardware is becoming an issue, as well, consider virtualizing the system using a modern virtualization solution. Then apply the firewalling above. Server 2003 seems to be easily virtualized and most modern solutions can handle it trivially.Hardware failure of many of these aging systems is their largest risk in terms of availability.

3. Eliminate the need AS SOON AS POSSIBLE. Even with the firewalling and filtering, these systems have high risk. You might also consider if you can migrate portions of the services from Windows 2003 to a more recent system or platform. This isn’t always possible, but everything you can move from Windows 2003 to a supported OS is likely to let you crank down your filtering even more.

Lastly, if you’re still trapped on Windows 2003, make sure you review this every quarter with the application owners and management. Keep it on their mind and on the front burner. The sooner you can resolve it, the better. 

If you need more help or advice on risk mitigation or minimization, get in touch. We’d love to help! Just email us at info@microsolved.com and we can connect.

An Example Control Matrix for Supply Chain Security

Posted on by
5
Per the examples in the last post, here is what the Control Matrix for Vendor Supply Chain Security might look like.
 
In the beginning of the document, you can define the audience, the authors, the update process and the process for handling exceptions. I usually also add a footer that has relevant reference links to products/services/vendors and key terms used in the document.
 
The main content, of course, is the matrix itself, which usually looks something like this:
 
 
Name of Tier Tier Criteria Required Diligence Required Controls
Critical Risk Vendors Shared IIP that allows duplication of products or differentiator features or R&D; ANY outage of the vendor’s IT operations would harm JIT delivery or line manufacturing Any required regulatory document gathering (SAS70, PCI DSS, HIPAA, etc.); Monthly MSI passive assessment – MEDIUM or HIGH risk issues trigger FULL risk assessment & review of their security audits; MSI monitors vendor list for Targeted Threat Intelligence and if triggered, formal incident response process is required from the vendor
As determined by your firm…
All controls required – NO VARIANCE ALLOWED
High Risk Vendors Shared non-critical IIP that allows feature replication, long term damage to product/brand strategy or R&D; Protracted outage of the vendor’s IT operations could impact production Any required regulatory document gathering (SAS70, PCI DSS, HIPAA, etc.); Quarterly MSI passive assessment – HIGH risk issues trigger FULL risk assessment & review of their security audits
As determined by your firm…
All controls required – NO VARIANCE ALLOWED
Routine Risk Vendors IIP shared at this level represents a potential for reputational or regulatory impacts; Normal vendor level where data sharing occurs Any required regulatory document gathering (SAS70, PCI DSS, HIPAA, etc.); Yearly MSI passive assessment – HIGH risk issues trigger deeper risk assessment
As determined by your firm…
Variance allowed by signed acceptance from steering committee or executive team
Low Risk Vendors Data is not shared with this vendor and compromise of the vendor’s IT operations is unlikely to have any impact Peer review to validate tier eligibility; Contract language review; Financial fraud team validation Only contractual controls and/or SLA required
 
As you can see, the matrix makes the entire program easy to discuss and demonstrate. The more clearly you can define the tiers, their required due diligence, their required controls and other data elements – the easier the process gets. 
 
We hope this helps you put together your own vendor tiering program and easily demonstrate it. If you would like more information about our passive assessment platform or Targeted Threat Intelligence (passive monitoring of vendor-related IOCs and security issues), please touch base with your account executive. Many of our clients are actively using and recommending these offerings for their supply chain security initiatives. We’d love to tell you more about it, so just let us know! 
 

Mapping Control Requirements to Vendor Tiers

Posted on by
4
Now that you have a proper tier structure set up for your vendors, we will discuss how to map controls to each of those tiers to create a control matrix that you can work from. This control matrix will serve as the basis for the vendor supply chain security effort – essentially providing a skeleton of the due diligence that you will perform for each vendor. Once this matrix is complete, you can use it to clearly and easily demonstrate the work that your organization does on supply chain security to any auditor or regulator who may ask to review it. In our experience, walking them through the matrix, along with providing them a documented process that you follow to enforce the matrix will suffice to meet most regulatory requirements – assuming of course, that you actually perform the work detailed in the matrix.
 
So – at a high level, how do we assign the controls? I usually start at the bottom of the stack of tiers and define the minimum controls first. Thus (referring back to the tier structure defined last time around):
  • Low Risk Vendors– What are the minimum steps we should perform for each vendor in this tier?
    • Controls Required: Scoping peer review to ensure that the criteria for this tier are met; contract and, when applicable, SLA review by the security team against established guidance & regulatory requirements, approval of financial due diligence team to avert fraud, etc. 
      • Comments: Since there are only isolated potentials for digital risk in this tier, we don’t need to perform cyber-security reviews and the like, or accumulate data we don’t need (which wastes time & resources, etc.). If, for example, this is a commodity or non-impactful application provider, we might review their contract for language around malware free deliverables, code security, patch/fix turnaround times, etc., as appropriate for each vendor and the service or good they provide.
  • Routine Risk Vendors – At this level, I try and think of the controls that I would want for just about any vendor that can impact us or our operations, but that aren’t capable of doing much beyond reputational or regulatory damage.
    • Controls Required: All of the controls of the lower level apply and are required. Any control reviews that are required for regulatory compliance over PII that we share (SAS70, PCI-DSS compliance statements, etc.). Plus, at this stage, I would really like some form of cyber-security assessment, which in this case is MSI’s passive assessment tool (that can be run without the vendor’s knowledge or permission) run against them on a yearly basis with NO HIGH RISK issues identified. If a HIGH RISK issue is found, then they would be flagged and would need to have a formal technical review of their security controls performed or even our traditional risk assessment process. Any deviance from the accepted controls would require a signed risk acceptance variance from a management team or steering committee, as an example.
      • Comments: Here, we are defining the basics. What do we need for most vendors that could hurt us? We try to keep the process as simple as possible, so that we can focus on the vendors that have higher risk of actually hurting us and our business. The use of passive assessments here is a powerful new approach to reduce the number of full fledged risk assessments that we need to perform, and the overhead created by dealing with the paperwork and interactions to complete the traditional risk assessment process.
  • High Risk Vendors – Here we build on the controls below for normal vendors to try and achieve a balance between work load and information security needs. We define a level that exceeds best practices and serves to give us more confidence in the vendors that could hurt us at a significant level.
    • Controls Required: All of the controls of the lower levels apply and are now definitely required(no variances accepted at this level for the basic controls defined for lower risk levels). In addition, we need to provide ongoing assessment of the vendor’s security controls, so a passive run is now required without any HIGH RISK findings on a quarterly basis. This is to help us combat control drift and control entropy in the vendor’s security posture. If at any time, a HIGH RISK issue is identified, then a FULL and COMPREHENSIVE risk assessment is required as soon as possible. This risk assessment should include the review of the vendor’s third party risk assessments, vulnerability assessments & penetration tests (these should be provided to us by the vendor, within 3 business days of the request). Failure to pass this risk assessment, respond properly or any significant issues identified that are not mitigated in a timely manner should result in financial and legal consequences for the vendor and their contract with our organization.
      • Comments: Again, we are trying to reduce the incidence of full risk assessments, so that we can focus our attention and limited resources on the vendors that can hurt us significantly and are in the worst security postures. Further, we create an incentive at this level for them to comply and respond rapidly.
  • Critical Risk Vendors – These are the vendors that can REALLY hurt us, so we spend a majority of our attention and resources here. 
    • Controls Required:  All of the controls of the lower levels apply and are now definitely required(no variances accepted at this level for the basic controls defined for lower risk levels). Additionally, passive assessments are now monthly in frequency (or maybe even weekly, depending on your paranoia/risk tolerance). Ongoing monitoring of target threat intelligence data is also required – so we are having MSI monitor social media/public web/deep web/dark web for any events or indicators of compromise that might emerge and be related to our vendors in this tier. At this level, we are performing the full comprehensive risk assessment process on a yearly basis, in addition to the passive work of MSI. While this is tedious, we want to ensure that we have provided the utmost effort on these vendors that can truly hurt us at the most damaging of levels. We can now do this easily without taxing our resources, thanks to the tiering architecture and the use of the focus points provided by MSI through our passive assessment and other services. Any identified MEDIUM or HIGH RISK issue flagged by MSI results in the immediate triggering of an update to the risk assessment process, notification of the vendor for the required response of their security team leadership, and the potential requirement for a formal incident response process for the vendor – which we manage by requiring the delivery of an incident response report and/or attestation by a third party security firm that the situation was mitigated and that our IIP was protected. Failure to pass this risk assessment, respond properly or any significant issues identified that are not mitigated in a timely manner should result in SIGNIFICANT financial and legal consequences for the vendor and their contract with our organization.
      • Comments: Here we leverage ongoing monitoring and take the lead on watching for potential compromises for ourselves and our vendors. Given the large percentage of breaches reported by third parties, we no longer believe that the detection and response capabilities of any partner organization are strong enough, alone, to protect our IIP. Thus the increased due diligence and oversight for the vendors that can hurt us the worst.

As you can see, building from the ground up makes leveraging the tiering process easy and logical. In the next post we will show you an example controls matrix we use to demonstrate and discuss our vendor supply chain security process. Over the years, we have found the matrix to be a powerful, auditor/regulator friendly tool to show clearly and concisely the due diligence process for vendor supply chain security. We hope you find it useful as well. Stay tuned! 

Sorting Vendors into Tiers

Posted on by
5
Previously, we reviewed some ideas around vendor discovery and laid out an example workflow and process. We also defined some tools and approaches to use for the task.
 
Once you have the vendors in your supply chain identified, and have obtained and cataloged the relevant data, the next step we suggest is to tier the vendors into levels to make it easier to classify vendors into “object groups”. Once we have the vendors sorted into tiers, we will discuss how to assign required controls to each tier in an easy to manage manner. This greatly simplifies the processing of future vendors that are added to the supply chain, since you need only identify the tier they fit into and then use the control requirements for that tier as your basis for evaluation and risk assessment. 
 
Vendor tiering, done properly, also makes assigning vendors to a given tier trivial in the long term. Our approach, as you will see, provides very clear criteria for the levels, making it easy to add new vendors and simple to manage vendors who change status as the supply chain and product lines evolve.
 
In our suggested model, we have four tiers, comprised as follows (using a product manufacturer as an example, obviously, other types of firms may require alternate specific criteria, but this should serve to lay out the model for you use as a baseline):
 
  • Critical Risk Vendors
    • Criteria: Mission critical “information intellectual property” (IIP) assets are shared with this vendor, where the assets represent a significant portion of the market differentiator or research and development of a product line OR the vendor’s IT operations are critical to our just in time manufacturing or delivery model – that is – ANY outage of the vendor’s IT operations would cause an outage for us that would impact our capability to deliver our products to our customers
      • Examples: Compromise of the IIP data would allow duplication of our product(s) or significant replication of our research; Outages or tampering with the vendor IT operations would impact manufacturing line operations, etc.
  • High Risk Vendors
    • Criteria: Non-critical IIP assets are shared with this vendor such that if said assets were compromised, they would represent damage to our long term product & brand strategies or research and development. Actual product replication would not be enabled, but feature replication might be possible. Outages of vendor’s IT operations at this level, if protracted, could impact our research and development or ability to deliver our products to our customers.
      • Examples: Breach of this vendors network could expose the design specs for a specific part of the product. Compromise of the vendor could expose our future marketing plan for a product and some of the differentiating features that we plan to leverage. If the vendor’s IT operations were disabled for a protracted time, (greater than /48, 72 or 96/ hours), our capability to deliver products could be impacted.
  • Routine Risk Vendors
    • Criteria: Non-critical IIP assets may be shared with this vendor tier, and compromise of that IIP may be damaging to our reputation. The IIP, if compromised, would not allow duplication of our product lines, research or differentiators of our products. In addition to reputational impacts, share of data that could impact our sales pipeline/process and/or other secondary systems or processes may be expected if breaches occur at this level. Regulatory or legally protected IIP also resides at this level.
      • Examples: Organizations where customer data, sales & marketing data, employee identification information, etc. are shared (outsourced payment, outsourced HR, etc.) are good examples here. This is the level of risk for any vendor that you share IIP with, in any form, that does NOT immediately empower delivery of your products or impact your longer term R&D efforts or market differentiators… 
  • Low Risk Vendors
    • Criteria: This tier is for vendors that we share NO IIPwith, in any form, and vendors that could not directly impact our product delivery via an IT operations outage in any way. These vendors, should they experience a breach, would result in little to no impact on the reputation or capabilities of our firm to operate.
      • Examples: Caterers, business supply companies, temporary employment agencies, hardware and software vendors for not manufacturing systems, commodity product or component dealers, packaging material suppliers, transport companies, etc.
 
Building such a tiered approach for your vendors creates an easy to manage way to prioritize them. The tiered approach will also be greatly useful in mapping groups of controls to the requirements for each tier. We will cover that in a future post, shortly. 

How to Avoid Getting Phished

Posted on by
Reply
It’s much easier for an attacker to “hack a human” than “hack a machine”.  This is why complicated attacks against organizations often begin with the end user.  Although e-mails with malicious links or attachments are often dismissed and referred to as “spam”, these messages are often the beginning of a sophisticated hack against a company.  Unfortunately there is no “silver bullet” that can prevent these attacks from taking place.
 
I recently had the opportunity to give a presentation during one of our client’s all-staff meeting.  Despite the fact that our client’s company resides in a relatively niche market, I was able to discuss several data breaches that took place in their industry within the last year.  Not only did the hacks all take place recently, they were all the direct result of actions taken by an end-user.  A majority of these attacks were caused by an employee opening a malicious e-mail.  I gave our customer the following advice to help them avoid becoming a victim of Phishing e-mails and felt that it was worth sharing on StateOfSecurity.com.
 
Verify link URL:  If the e-mail you received contains a link, does the website URL match up with the content of the message?  For example, if the e-mail indicates you are about to visit a website for FedEx, is the address actually FedEx.com?  A common tactic used by attackers is to direct a user to a similar URL or IP address.  An example of this would be to direct the user to FedEx111.com or FedEx.SE as opposed to the organization’s actual URL.
 
Verify e-mail address of sender: If the e-mail message you received came from a friend, colleague or vendor, did it actually come from their e-mail address?  It’s worthwhile to take a few extra seconds to ensure that the e-mail actually came from the aforementioned colleague, friend or vendor.  Also, avoid opening e-mails from generic senders such as “Systems Administrator” or “IT Department”.
 
Exercise caution from messages sent by unknown senders: Be cautious if a message comes from an unknown sender.  Would you provide your checking account number or password to a random person that you saw on the street?  If not, then don’t provide confidential information to unknown senders.
 
Follow up with a phone call: In the event you receive a message requesting that you validate information or need to reset your password, take some time to follow up with the sender with a phone call.  Trust me, your IT department will be happy to spend a few seconds confirming or denying your request as opposed to dealing with a malware infection.  Also, if your “bank” sends any type of e-mail correspondence requesting that you perform some sort of action, it’s worthwhile to give them a call to confirm their intentions.  Always be sure to use a number that you found from another source outside of the e-mail.
Spot check for spelling/grammar errors: It is extremely common that malicious e-mails contain some sort of spelling mistake or grammatical error.  Spelling mistakes or grammatical errors are great indicators that you have received a malicious e-mail.
 
Do not open random attachments: If your e-mail messages meets any of the above criteria, DO NOT open the attachment to investigate further.  Typically these attachments or links are the actual mechanism for delivering malware to your machine.
 
This blog post by Adam Luck.

Data Breaches are a Global Problem

Posted on by
Reply

For those of you who maybe just thought that data breaches were only happening against US companies, and only by a certain country as the culprit, we wanted to remind you that this certainly isn’t so.

In fact, just in the last several weeks, breaches against major companies in the UK, Australia, Japan, Kenya, Korea, China and others have come to light. Sources of attacks show evidence of criminal groups working from the US, Brazil, Northern Africa, the Middle East, Russia and Asia among others. Just follow the data for a few weeks, and it quickly becomes clear that this is a GLOBAL problem and is multi-directional.

Even loose alliances seem to come and go amongst these criminal groups. They often steal data, talent, techniques, tools and resources from each other. They work together on one deal, while treating each other as competitors in other deals simultaneously. The entire underground is dynamic, shifting in players, goals and techniques on almost moment by moment basis. What works now spreads, and then gets innovated.

This rapidly changing landscape makes it hard for defenders to fight against the bleeding edge. So much so, in fact, that doing the basics of information security and doing them well, seems to be far more effective than trying to keep up with the latest 0-day or social engineering techniques.

That said, next time you read a report that seems to cast the data breach problem as a US issue versus the big red ghost, take a breath. Today, everyone is hacking everyone. That’s the new normal…

Twitter Games from MicroSolved

Posted on by
Reply

If you haven’t followed us on Twitter (@microsolved) yet, be sure to do so. Here are a few reasons why you should look to our Twitter feed for more great content from MSI:

  • Ongoing curated news feeds of some of the most interesting and best information security news & event coverage
  • Discussions of emerging threats and significant issues around InfoSec
  • Pointers to free tools & resources to help your team protect your data & systems
  • Easy way to talk to us & engage in pro-bono Q&A sessions
  • AND NOW – 2 New Games a week:
    • Mondays will feature the “Hacker Challenge” – a weekly technically-focused fun activity or challenge (decrypt a secret, solve a puzzle, find something specific  across the net, etc.)
    • Thursdays will feature the “Throw Back Thursday Hacker Trivia” – weekly trivia contest focused on hacker, InfoSec and technology; with occasional prizes for the winners!

So, grab an account on Twitter or follow us there, and don’t just keep up to date, but talk to us. We want to hear your thoughts, the security challenges you are facing and anything that will help us serve your information security needs. Plus, we know reading log files and patching systems can get tedious, so we will try to mix in a little fun along the way! See you there!

Touchdown Task for June: Document Cleanup

Posted on by
2

With the beginning of a new fiscal year on the immediate horizon for many, it reminds us that it’s time to clean up our books and our filing. And by that we mean both our digital and physical files! If you don’t already have a written document retention policy, one needs to be drafted. It should be tailored to your business needs and meet the requirements identified in local, state or federal laws and regulations that apply to your particular industry. 

As a part of your document retention plan, you will establish a document retention schedule of what to keep and for how long. Once you have this identified, it’s time to dive into the files, both paper and electronic, to see what should be properly destructed. 

It is critical that paper documents are either incinerated or shredded. Electronic files must be properly sanitized and purged. Purging can be accomplished a variety of secure erasing tools. A quick Google will turn up several free or low cost solutions. Clearing electronic data is often accomplished by overwriting existing data using software that incorporates a fixed sequence of characters. 
Whatever the processes are that you elect to perform, it is imperative that you stick to the schedule and destroy your documents per your written guidelines in your document retention policy.

Thanks to Teresa West for this post.