The three previous blogs in this series have covered Packet Analysis, Log Analysis and Threat Intelligence; this final article aims to bring all of this information into one cohesive solution for any SOC or Cyber Defence organisation. For further reading on this subject please see our presentation at last year’s RSA Conference in Abu Dhabi or read about it in the forthcoming book “Advanced Cyber Security: Using Intelligence Driven Counter Measures to Defend Against Cyber Attacks” (Wiley Corporate)
Before I joined RSA I had worked as an Analyst and Malware Analyst for the UK’s Ministry of Defence and as CIRT team leader in various defence contractors’ organisations. Use Cases were not something that at that time were being utilised anywhere. Sure we always had rigorous detection capabilities in place and reacted to any attack deploying out content rules and signatures to detect further bespoke attacks but it was not until reaching RSA that I realised that there is a far better way of doing this. Working with a number of RSA Advanced Cyber Defence (ACD) consultants, but especially with Angelo Perniola we developed an open Use Case Framework which can be utilised in any Cyber Security organisation.
However, before I get to that first we have to identify the Attack Scenarios which our organisation is faced with. This type of assessment must be conducted at a high level between SOC and Business Managers as well as Network Architects to identify the specific cyber threats to the business. This is typically establishing the type of Threat Actor that the business will face i.e. Nation State attacks, Activist Groups, cyber criminals etc. Once the expected Attack Scenarios are identified research can take place to identify Techniques, Tools and Procedures (TTP’s) utilised by the attackers (from Online Research, observed network traffic, historical Incidents and Threat Intelligence)
Table 1: Spear Phishing Attack Scenario
Kill Chain Phase
Scenario
Possible Use Cases
Reconnaissance
· Company employee (Target) posts current project/interests/company position to LinkedIn
· Attacker obtains contact information from LinkedIn
Weaponisation
· Attacker prepares C2 servers and drop zone servers on the Internet
· Attacker drafts plausible email to target
· Checks attachment (malware dropper) is not detected by AV
Delivery
· Attacker sends email to garget from Gmail account
· Email and Attachment pass company AV protection
· ZIP attachment with password in email text
· Suspicious file type download
Compromise
· Target opens email on his company Windows 7 computer, opens ZIP attachment, double clicks on the alleged PDF
· EXE is executed, uses an unpatched vulnerability on Windows 7 for privilege escalation (NT AUTHORITY\SYSTEM), installs several files in %SystemRoot% and adds/modifies several registry keys
· Endpoint Malware Infection
· New Program (not Whitelisted) executed
Installation
· Persistence is achieved through installation of a Windows service which terminates itself after RAT is launched
· RAT is running through Process Hollowing of SVCHOST process
· RAT sends beacon and opens back channel to C&C server using HTTP via company’s HTTP proxy server
· Suspicious Proxy Action
· New Program (not Whitelisted) execution followed by Network Traffic
C2
· Attacker obtains locally stored password hashes (identical local admin password is on all workstations in the company), obtains hash of user account in Domain Admin group on another workstation computer
· All C&C communication is from compromised computer(s) to C&C servers via HTTP during local office hours
· C2 Blacklist
· Domain accessed & NOT in ALEXA 500 top
· Protocol Anomalies
Actions
· Attacker connects to all computers in the Windows Domain (e.g. net use / psexec) searching for “interesting” files
· Attacker collects files via windows file sharing on a central computer and packs them in an encrypted RAR archive
· Uploads RAR to drop zone servers over HTTP via company’s HTTP proxy server
· Local Admin Usage
· Same User credentials on multiple hosts
· Outbound RAR Detected
The scenario above is one which every organisation faces these days with 91% of attacks originating from Phishing attempts. This Attack Scenario lists out various stages the attack has to go through to compromise a system and various Use Cases which can be implemented to detect and thwart the attack at various stages. Using this technique has enabled us to identify 12 Use Cases to start our Use Case Library.
But what actually comprises our Use Case? Over the last 2 years the RSA ACD team has developed a framework from our experience gained working in multiple different Global SOC’s and Cyber Defence Organisations. The Framework itself is broken down into 8 key areas:
Objective
Threat
Stakeholders
Data Requirements
Logic
Testing
Priority
Output
This gives us a full capability to Detect and Respond to the identified Threat. It also enables an organisation to transfer their Use Case Library to another vendor if the need arises as only the Logic portion will have to be assessed once more.
The Objective of the Use Case is to identify what we want to accomplish; in this case to detect and respond to a Phishing Attack. By having a defined objective everyone from the Analysts to the Content Engineers and Managers are aware of their specific taskings. This improves the overall effectiveness of the SOC by targeting resources.
The Threat is ultimately what we are looking to detect. A number of Threat Scenarios should be given as examples and any previous examples of attacks against the company should be listed (as well as links to Incidents within the Incident Management (IM) tool).
Stakeholders in this case are not necessarily the actual Business Management or the Owners of the Use Case but the actual analytical staff who are involved in the detection of threats and the remediation activities. This can also include external Stakeholders where Law Enforcement, Contractors or MSSP’s are involved.
Moving on to our detection capability Data Requirements form the individual data sources (Logs, Packets, Netflow etc.). These can be viewed from a high level point of view i.e. IDS Logs, Firewall Logs and the low level i.e. SNORT Syslog’s, Cisco ASA Logs giving specific details as to the log required
Our Logic portion of the Use Case is where we take our Data Requirements and translate that into Detection Rules or Signatures. Again we can have a high level design as shown in the simple example at Table 2 below. This should however be supplemented in the final document with the actual version of the Content/Signature deployed.
Table 2: Simple Detection Logic
Generic Attack Logic
Meta Description
Operator
Search String/Data
Device Class
IS
Anti-Spam OR IDS OR ENDPOINT
Anti-Spam Tools
Contains
“suspicious” OR “high risk file type” OR “poor reputation” OR “malware”
IDS
Contains
“executable” OR “suspicious” OR “poor reputation” OR “malware”
ENDPOINT
Contains
“executable” OR “suspicious” OR “poor reputation” OR “malware” OR “{hash}”
Group By
“{hash}” OR “user”
Threshold
>=1 Distinct
Now that we have our detection capability sorted out we are all good yeah? How do we know it actually works and detects the threat we are seeking? We must conduct Testing to ensure that our signature/content rule works as we expect it to. Not only is the testing of the rule paramount here but the Testing script/scenario must also be valid; if it is incorrect and our content rule is working correctly we may generate false results and as a result take a decision to not deploy the rule into production.
Each content rule/signature deployed should have an associated Priority which will allow the SOC analyst to correctly Triage Incidents in order. This also comes into the Logic portion of the Use Case i.e. Normal User = P2 Incident whereas VIP User/Asset or previously compromised asset = P1 Incident.
The final portion of the Use Case Output can be delivered in a number of ways with the most common being a Report, part of a Dashboard or aligned against an Incident Response Procedure. If your IM tool can accommodate it this is where the most bang for your buck comes in from your Use Case; as when the detection rule fires an alert into your IM suite the Incident Response Procedure you have assigned to this rule can automatically be loaded for the analysts to follow (as a shameless plug RSA’s Netwitness SecOps Manager can do just this.
Hopefully this whistle stop tour of Use Cases has given you some ideas to drive your security program forward and take a view to moving your program from a Reactive model to that of an Intelligence Driven Advanced SOC which is Proactive in its mission.
The post The Realm of Threat Intelligence – Attack Scenarios and Use Cases appeared first on Speaking of Security - The RSA Blog.