Is Your Adversary Your Supply Chain?

The Airbus breach teaches a clear lesson; organizations cannot solely focus on monitoring and protecting their own infrastructure, they must also manage the risk brought on by their supply chain business partners. However, more and more organizations struggle to operate and maintain their security environment, so where can they find the time or the talent? I’ll let you in on a little secret – if an organization has the funds to operate a SOC, then that organization should have the means to protect their critical data and identify risky behavior through access and usage monitoring.

What constitutes normal vs. risky varies from business to business. With no standard models for access and monitoring controls, developing suitable content for the SOC can challenge even the most experienced professional. Furthermore, without involvement and direction from business stakeholders, SOC content authors can overlook key business-specific requirements that can highlight vital threat signals from normal activity.

In the case of Airbus, threat actors compromised their network perimeter through the use of legitimate VPN credentials of a supply chain partner. The activity from this intrusion should be different from historical and comparative analysis for partners on this infrastructure. Then how is an organization able to identify the differences in expected behavior of a specific user? What are the signs to look for?

• Time-of-access patterns
  • When the user typically accesses the system, for how long, and from where
• Activity consistent with internal reconnaissance
  • The user is accessing information outside of their responsibilities
  • Appearance of network-level probing from the user
  • The user is crawling intranet resources (i.e. networked directories, knowledge bases, file shares)
• Activity consistent with data exfiltration
  • Large data transfers
  • Outbound data transfers via VPN, SSH, or internet
  • P2P filesharing

On its own, a user showing activity consistent with one of these bullets does not warrant investigation. There are a multitude of reasons a user may need to access the system outside of their typical hours or look over a networked directory – but if a user is participating in multiple of these suspicious behaviors there is cause for concern and investigation.

Before an organization is even prepared to give an outside party access to their systems, they should know the answer to these questions:

• Who is going to access the system?
• What is the user going to access?
• What permissions will the user have through the VPN?
• When will the user access the system, and is that time “normal”?
• Where will the user be located, and is that location “normal”?
• Why will the user need to access the particular system?

If the business process stakeholder cannot answer these questions, access and credentials to the system should be withheld from the user. However, the Airbus attackers “were able to successfully mirror working times and patterns” of the key project stakeholders, allowing them to stay in their system undetected. If the attacker’s activity is disguised under legitimate credentials, and a majority of their activity appears “normal”, then how can an organization identify or stop them before they complete their objectives?

In the Airbus attack, threat actors removed the forensic artifacts left behind from their tools and cleared the log files after their execution. Unauthorized or unexpected deletion of logs in an environment should be a huge red flag – one the organization should be aware of. If a log source does not deliver logs that the SOC anticipates, there should be an immediate investigation as to why and how those logs were not delivered. 

As a preventative measure for system alteration, logs should be delivered to a secondary – secure – location for the organization’s SOC. If the primary system integrity is compromised and altered, the SOC should have backups of the original state for comparison. The use of an Endpoint Detection and Response (EDR) agent should also be used on critical business systems to periodically collect snapshots of forensic evidence for investigation. 

At this point you may be thinking: “Okay, great – but I’m not Airbus. What if my organization doesn’t have the funding that Airbus has? It is hard enough to manage our own infrastructure, how are we supposed to have the means to monitor our partners’? How can this be funded? Where do I even find the talent to implement these processes?”

Centralizing automation and built to break vendor dependency, ThetaPoint’s Security Reference Architecture (SRA) reduces the complexity of alerting to introduce more talent into the SOC pipeline. Through automation, the SRA allows you to increase the effective talent within your SOC for investigation and remediation, and the consistency of their findings. Organizations that build an effective and cost-efficient model for the SOC are able to monitor the access and usage of their most critical data in a way that is concise, consistent, and less resource intensive.