HPSS and Splunk

We’ve had a few users ask how to feed alerts from the HPSS Console into a SIEM. In these cases it was Splunk, so I will show how to quickly get a feed going into Splunk and some basic visualizations. I chose Splunk since that’s what I helped the users with, but any SIEM that will take syslog will work.

The first step is to get the HPSS Console set up to externally log events. This can be enabled by checking the “Enable System Logging” in the preferences window. What happens with the output depends on your OS. On Windows the events are written to Event Log, and on Linux/MacOS they are handled by the syslog daemon. Alternatively you can use the Console plugins system if syslog/eventlog is not flexible enough.

HPSS Preferences Window

Before we go further, we’ll need to configure Splunk to read in the data, or even set up Splunk if you don’t have an existing system. For this blog post, I used the Splunk Docker image to get it up and running a couple minutes in a container.

In Splunk we’ll need to create a “source type”, an “index” and a “data input” to move the data into the index. To create the source type, I put the following definitions in the local props.conf file located in $SPLUNK_HOME/etc/system/local (you may need to create the props.conf file)

[hpss]
EXTRACT-HPSSAgent = Agent: (?P<Honeypoint_Agent>[^ ]+)
EXTRACT-Attacker_IP = from: (?P<Attacker_IP>[^ ]+)
EXTRACT-Port = on port (?P<Port>[^ ]+)
EXTRACT-Alert_Data = Alert Data: (?P<Alert_Data>.+)
TIME_PREFIX = at\s
MAX_TIMESTAMP_LOOKAHEAD = 200
TIME_FORMAT = %Y-%m-%d %H:%M:%S

This tells Splunk how to extract the data from the event. You can also define this in the Splunk web interface by going to Settings -> Source Types and creating a new source type.

Source Type definition

Next create the Index under Settings -> Indexes. Just giving the index a name and leaving everything default will work fine to get started. 

To create a Data Input, go to Settings -> Data Inputs.  I’m going to set it up to directly ingest the data through a TCP socket, but if you already have a setup to read files from a centralized logging system, then feel free to use that instead.

 Set the port and protocol to whatever you would like.

For the source type, manually typing in “hpss” (or whatever you named it) should bring up the already defined source type. Select that, and everything else can remain as is. Then go to review and finish. It’s now ready for you to ship the events to it.

Lastly, we need to get the logs from the Console system to Splunk. Again, this will differ depending on your OS. I will show one way to do this on Windows and one for Linux. However, there are numerous ways to do it. In both cases, replace the IP and Port of your Splunk instance.

On Windows you can use NXLog or another type of eventlog to syslog shipper. After installing NXLog, edit the following into the configuration file.

define ROOT C:\Program Files\nxlog
#define ROOT C:\Program Files (x86)\nxlog

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log

<Input in>
Module im_msvistalog
Query <QueryList>\
<Query Id="0">\
<Select Path="HPConsole">*</Select>\
</Query>\
</QueryList>
SavePos TRUE

</Input>

<Output out>
Module om_udp
Host 192.168.232.6
Port 1514
</Output>

<Route 1>
Path in => out
</Route>

On Linux with rsyslog, create a conf file with the following

:msg,contains,"HPSS Agent" @@192.168.232.6:1514

Now Splunk should be receiving any HPSS events sent to it and storing them in the defined index, and extracting the fields during search queries.

In the future we can look at creating some graphs and analyze the events received. If there is any interest, I can look at creating a Splunk app to configure all of this for you.

Last Quick and Dirty Log Tip for the Week

OK, so this week I posted two other blog posts about doing quick and dirty log analysis and some of the techniques I use. This one also covers converting column logs to CSV.

After the great response, I wanted to drop one last tip for the week. 

Several folks asked me about re-sorting and processing the column-based data in different ways and to achieve different analytical views. 

Let me re-introduce you to my friend and yours, sort.

In this case, instead of using the sort -n -r like before (numeric sort, reverse order), we can use:

  • sort -k# -n input_file (where # is the number of the column you’d like to sort by and the input file is the name of the file to sort)
    • You can use this inline by leveraging the pipe (|) again – i.e.: cat input.txt | sort -k3 -n (this types the input file and sends it to sort for sorting on the third column in numeric order) (-r would of course, reverse it…)
    • You can write the output of this to a file with redirects “> filename.txt”, i.e.: cat input.txt | sort -k3 -n -r > output.txt
      • You could also use “>>” as the redirect in order to create a file if it doesn’t exist OR append to a file if it does exist… i.e..:  cat input.txt | sort -k3 -n -r >> appended_output.txt

That’s it! It’s been a fun week sharing some simple command line processing tips for log files. Drop me a line on Twitter (@lbhuston) and let me know what you used them for, or which ones are your favorite. As always, thanks and have a great weekend! 

Quick And Dirty Log Analysis Followup

Earlier this week, I posted some tips for doing Quick and Dirty PA Firewall Log Analysis.

After I posted this, I got a very common question, and I wanted to answer it here.

The question is something along the lines of “When I use the techniques from your post, the outputs of the commands are column separated data. I need them to be CSV to use with my (tool/SEIM/Aunt Gracie/whatever). How can I convert them?” Sound familiar?

OK, so how do we accomplish this feat of at the command line without all of the workarounds that people posted, and without EVER loading Excel? Thankfully we can use awk again for this.

We can use:

  • awk ‘BEGIN { OFS = “,”} ; {print $1,$2,$3}’
    • Basically, take an input of column data, and print out the columns we want (can be any, in this case I want the first 3 columns), and make the outputs comma delimited.
    • We can just append this to our other command stacks with another pipe (|) to get our output CSV
  • Example: cat log.csv | awk ‘BEGIN { FS = “,”} ; {print $8,$9}’ | sort -n | uniq -c | sort -n -r | awk ‘BEGIN { OFS = “,”} ; {print $1,$2,$3}’
    • In this example, the source IP and destination IP will be analyzed, and the reduced to unique pairs, along with the number of times that that pair is duplicated in the input log (I use this as a “hit rate” as I described earlier
      • A common question, why do I ask for two columns in the first awk and then ask for three columns in the second awk?
        • The answer of course, is that the first awk prints the unique pairs, but it also adds a column of the “hit rate”, so to get the output appropriately, I need all three fields.

So, once again, get to know awk. It is your friend.:)

PS – Yes, I know, there are hundreds of other ways to get this same data, in the same format, using other command line text processing tools. Many may even be less redundant than the commands above. BUT, this is how I did it. I think it makes it easy for people to get started and play with the data. Post your ways to Twitter or share with the community. Exploration is awesome, so it will encourage users to play more. Cool! Hit me on Twitter if you wanna share some or talk more about this approach (@lbhuston).

Thanks for reading!

Quick & Dirty Palo Alto Log Analysis

OK, so I needed to do some quick and dirty traffic analysis on Palo Alto text logs for a project I was working on. The Palo Alto is great and their console tools are nice. Panorama is not too shabby. But, when I need quick and dirty analysis and want to play with data, I dig into the logs. 
 
That said, for my quick analysis, I needed to analyze a bunch of text logs and model the traffic flows. To do that, I used simple command line text processing in Unix (Mac OS, but with tweaks also works in Linux, etc.)
 
I am sharing some of my notes and some of the useful command lines to help others who might be facing a similar need.
 
First, for my project, I made use of the following field #’s in the text analysis, pulled from the log header for sequence:
  • $8 (source IP) 
  • $9 (dest IP)
  • $26 (dest port)
  • $15 (AppID)
  • $32 (bytes)
 
Once, I knew the fields that corresponded to values I wanted to study, I started using the core power of command line text processing. And in this case, the power I needed was:
  • cat
  • grep
    • Including, the ever useful grep -v (inverse grep, show me the lines that don’t match my pattern)
  • awk
    • particularly: awk ‘BEGIN { FS = “,”} ; {print $x, $y}’ which prints specific columns in CSV files 
  • sort
    • sort -n (numeric sort)
    • sort -r (reverse sort, descending)
  • uniq
    • uniq -c (count the numbers of duplicates, used for determining “hit rates” or frequency, etc.)
 
Of course, to learn more about these commands, simply man (command name) and read the details. 😃 
 
OK, so I will get you started, here are a few of the more useful command lines I used for my quick and dirty analysis:
  • cat log.csv | awk ‘BEGIN { FS = “,”} ; {print $8,$9,$26}’ | sort | uniq -c | sort -n -r > hitrate_by_rate.txt
    • this one produces a list of Source IP/Dest IP/Dest Port unique combinations, sorted in descending order by the number of times they appear in the log
  • cat log.csv | awk ‘BEGIN { FS = “,”} ; {print $8,$9}’ | sort -n | uniq -c | sort -n -r > uniqpairs_by_hitrate.txt
    • this one produces a list of the uniq Source & Destination IP addresses, in descending order by how many times they talk to each other in the log (note that their reversed pairings will be separate, if they are present – that is if A talks to B, there will be an entry for that, but if B initiates conversations with A, that will be a separate line in this data set)
  • cat log.csv | awk ‘BEGIN { FS = “,”} ; {print $15}’ | sort | uniq -c | sort -n -r > appID_by_hitrate.txt
    • this one uses the same exact techniques, but now we are looking at what applications have been identified by the firewall, in descending order by number of times that application identifier appears in the log
 
Again, these are simple examples, but you can tweak and expand as you need. This trivial approach to command line text analysis certainly helps with logs and traffic data. You can use those same commands to do a wondrous amount of textual analysis and processing. Learn them, live them, love them. 😃 
 
If you have questions, or want to share some of the ways you use those commands, please drop us a line on Twitter (@microsolved) or hit me up personally for other ideas (@lbhuston). As always, thanks for reading and stay safe out there! 

An Exercise to Increase IT/OT Engagement & Cooperation

Just a quick thought on an exercise to increase the cooperation, trust and engagement between traditional IT and OT (operational technology – (ICS/SCADA tech)) teams. Though it likely applies to just about any two technical teams, including IT and development, etc.

Here’s the idea: Host a Hack-a-thon!

It might look something like this:

  • Invest in some abundant kits of LittleBits. These are like Legos with electronics, mechanical circuits and even Arduino/Cloud controllers built in. Easy, safe, smart and fun!
  • Put all of the technical staff in a room together for a day. Physically together. Ban all cell phones, calls, emails, etc. for the day – get people to engage – cater in meals so they can eat together and develop rapport
  • Split the folks into two or more teams of equal size, mixing IT and OT team members (each team will need both skill sets – digital and mechanical knowledge) anyway.
  • Create a mission – over the next 8 hours, each team will compete to see who can use their smart bits set to design, program and proto-type a solution to a significant problem faced in their everyday work environments.
  • Provide a prize for 1st and 2nd place team. Reach deep – really motivate them!
  • Let the teams go through the process of discussing their challenges to find the right problem, then have them use draw out their proposed solution.
  • After lunch, have the teams discuss the problems they chose and their suggested fix.Then have them build it with the LittleBits. 
  • Right before the end of the day, have a judging and award the prizes.

Then, 30 days later, have a conference call with the group. Have them again discuss the challenges they face together, and see if common solutions emerge. If so, implement them.

Do this a couple times a year, maybe using something like Legos, Raspberry Pis, Arduinos or just whiteboards and markers. Let them have fun, vent their frustrations and actively engage with one another. The results will likely astound you.

How does your company further IT/OT engagement? Let us know on Twitter (@microsolved) or drop me a line personally (@lbhuston). Thanks for reading! 

Emulating SIP with HoneyPoint

Last week, Hos and I worked on identifying how to emulate a SIP endpoint with HoneyPoint Security Server. We identified an easy way to do it using the BasicTCP capability. This emulation component emulates a basic TCP service and performs in the following manner:

  • Listens for connections
  • Upon connection, logs the connection details
  • Sends the banner file and awaits a response
  • Upon response, logs the response data
  • Sends the response, repeating the wait and log loop, resending the response to every request
  • When the connection limit is reached, it closes the connection
It has two associated files for the emulation:
  • The banner file – “banner”
  • The response file – “response”

In our testing, we were able to closely emulate a SIP connection by creating a banner file that was blank or contained only a CR/LF. Then we added the appropriate SIP messaging into the response file. This emulates a service where thew connection is completed and logged, and the system appears to wait on input. Once input is received, then a SIP message is delivered to the client. In our testing, the SIP tools we worked with accepted the emulation as SIP server and did not flag any anomalies.

I’ll leave the actual SIP messaging as a research project for the reader, to preserve some anonymity for HPSS users. But, if you are an HPSS user and would like to do this, contact support and we will provide you with the specific messaging that we used in our testing.

As always, thanks for reading and especially thanks for being interested in HoneyPoint. We are prepping the next release, and I think you will be blown away by some of the new features and the updates to the documentation. We have been hard at work on this for a while, and I can’t wait to share it with you shortly!

How to Engage MSI for Supply Chain Security Help

The month of March is about to wrap up and come to a close. I hope it was a great month for you and your security initiatives. I also hope you took advantage of our focused content this month on Supply Chain Security. If you want to go back and read through some of the articles, here are quick links:

3 Reasons Your Supply Chain Security Stinks

Ideas for Vendor Discovery

Sorting Vendors into Tiers

Mapping Control Requirements to Vendor Tiers

An Example Control Matrix for Supply Chain Security

What is MSI’s Passive Assessment & How Does it Empower Supply Chain Security?

Many folks have asked us about how to engage with MSI around the Supply Chain. I wanted to add this bit of information in order to make it easier for folks to know how we can assist them.

You can engage with MSI around Supply Chain Security in three primary models:

  • Focused Mission Consulting Model – This model is when you have a specific set of tasks and deliverables in mind that you would like MSI to create/review/audit or test. We scope the work effort up front and provide a flat rate engagement price. The work is then completed, usually offsite, and the deliverables are worked through until completed. This is fantastic for organizations looking to build a program, create their tiers and control matrices and document the processes involved. Basically, you hire us to do the heavy lifting…
  • Retainer-Based Consulting Model – This model lets you hire MSI resources for a specific time frame (usually 1 year) for periodic oversight, design, review or operational tasks. Our team supplements your team, providing experience and assistance to your process. Basically, you do the heavy lifting – and we make sure you build an efficient, effective and safe program for supply chain security. This is a flat rate, billed monthly, for a set number of resource hours.
  • Virtual CISO Model – In this model, you can hire MSI to manage and provide oversight for security needs across the enterprise. You get an assigned MSI resource who is responsible for ensuring your initiatives get completed and performed in accordance with best practices. This resource can draw from other MSI subject matter experts and our services, as needed, to build out/supplement or support your security initiative. This is a great offering for small and mid-size organizations who need deep expertise, but who might not have the budget or capability to retain world class talent across multiple security domains. Basically, in this type of engagement – you hire us to solve your security problems and build/manage your security program. We do that with attention to cost/efficiency/effectiveness and safety. Pricing for this service type varies based on the maturity and requirements of the security program.

You can also retain MSI to leverage our passive assessment platform to assess your vendors passively, “en masse”. For information about how to engage with us to serve as a fulcrum for your security program, arrange for a free, no pressure, exploration call with your account executive. If you don’t have an account executive, give us a call at (614) 351-1237 or drop us a line at info (at) microsolved /dot/ com and let us know of your interest. We would love to share some demo information with you and walk you through how we can help.

If you have any other questions about Supply Chain Security or other issues, please get in touch, as above. You can also reach out to me on Twitter. As always, thanks for reading and until next time, stay safe out there!

What is MSI Passive Assessment & How Does it Empower Supply Chain Security

MSI’s passive assessment represents a new approach to understanding the security risks associated with an organization, be it yours or a vendor, prospect or business partner’s. MSI’s passive assessment leverages the unique power of the MSI TigerTrax™ analytics platform to perform automated research, intelligence gathering and correlation from hundreds of sources, both public and private, that describe the effective security posture of an organization.
 
The engine is able to combine the power of hundreds of existing tools to build the definitive profile of an organization’s security posture –  such as:
  • open source intelligence
  • corporate data analytics
  • honeypot sources
  • deep & dark net search engines
  • other data mining tools 
 
MSI’s passive assessment gives you current and historical information about the security posture of the target, such as:
  • Current IOCs associated with them or their hosted applications/systems (perfect for cloud environments!)
  • Historic campaigns, breaches or outbreaks that have been identified or reported in public and in our proprietary intelligence sources
  • Leaked credentials, account information or intellectual property associated with the target
  • Underground and dark net data associated with the target
  • Misconfigurations or risky exposures of systems and services that could empower attackers
  • Public vulnerabilities
  • Other relevant intelligence about their risks, threats and vulnerabilities – new sources added weekly…
 
Best of all, it gathers and correlates that data without touching the target’s network or systems directly in any way. That means you do not need the organization’s permission or knowledge of your research, so you can keep your interest private!
 
In the supply chain security use case, the tool can be run against organizations as a replacement for full risk assessment processes and used as an initial layer to identify and focus on vendors with identified security issues. You can find more information about it used in the following posts about creating a process for supply chain security initiatives:
 
Clients are currently using this service for M&A, vendor supply chain security management, risk assessment and to get an attacker’s eye view of their own networks or cloud deployments/hosted solutions.
 
To learn more about MSI’s passive assessment, please talk with your MSI account executive today!
 
 
 

An Example Control Matrix for Supply Chain Security

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

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!