So what
is a "Malware Reporting Standard"? In
short, a consistent way to report data and information about malware, usable by
everyone, for use by any tool. The bits
of malware information that all of us Information Technology and Infosec
professionals need to enter or import into our myriad of security solutions or
scripts that we may use.
Why is
this an issue? Have you ever read virus
descriptions from Sophos, Seculist/Kasperski, McAfee and others and tried to glean
some data to enter into a security tool or search script? Have you read the Mandiant APT1 report with
the IOC’s (MD5’s) listed in the Appendix document, the Kasperski Red
October report with the MD5’s listed, or even the
Kasperski WinNTI report which lacked any Indicators Of Compromise (IOC)?
So what
do we need? What we need is for all the
vendors and malware researchers to provide and report data about malware in a
concise format that makes it easy to identify and consume the valuable details
littered throughout the above mentioned reports and virus descriptions.
For many security
solutions, the following information is needed to create an analysis we use to
detect any anomalies;
- Filename
- Path found
- File extension
- MD5/SHA1
- Any Digital Signature info
- Dates
- Registry entries for Windozs systems
A security
professional does not necessarily need all the details to perform or setup an analysis. The path or location the file was found and
the extension of the file is fantastic information to setup an analysis for
anything odd. Look for anything in
location \XYZ with the extension of .ABC that was found in the last 24 hours
for example, and give me the SHA1 or MD5 of the file and maybe compare it to a
file with the MD5 or SHA1 of the known bad IOC’s
(if necessary). This is a better method
as now automated scans can look for a few files and compare it to an IOC list (if
necessary) versus checking every file on the system against the IOC MD5 list,
which is growing daily and will soon, if not already be out of control and unusable.
I am well
aware that there is unique malware tracked by Anti-Virus companies (no alert triggered to the user) that are purposefully kept secret. Whatever reason they are not alerted to the
end-user, legal, law enforcement and specific requests by customers not wanting
any details of an identified malware released while investigations are ongoing. We do not get to see these details
that can help protect us, we are denied!
There is no reason AV companies cannot add certain minimum bits and
still keep details secret. AV companies
can just add the following as a minimum to a monthly or quarterly report/list
for the secret “Shhh don’t alert” malware items;
- Location/path malware was found
- File extension of the malware
- Anything else in the Malware Reporting Standard
As a part of implementing a “Malware Management Framework” (we recommend
everyone start adopting), the review of malware reports, virus descriptions and any
malware analysis details is a fundamental part of the “Malware ManagementFramework” process. Look for the items
mentioned above within the last 24 hours using a tool like IBM Endpoint Manager
(formerly BigFix) or Tanium would allow you to detect even the “Shhh don’t alert” malware items” as suspicious or unknown files and
to investigate. If you used the "MalwareManagement Framework" approach, malware that dropped additional .OCX files in
System32 would be obvious as there are only 5 or 6 .OCX files normally in
C:\Windows\System32 as was seen in Gauss.
All you would need to know is to setup your analysis tools and/or
scripts to look for this condition in the last 24 hours and alert you for
example.
The
"Collective Intelligent Framework" (CIF) project is a step in the right
direction, but we need to take the feeds and schema used by CIF, OpenIOC and others and
standardize it. A researcher or AV
company can collect all or even parts of the bits of malware, but it must
report it in a standardized manner. Also
provide the data in two formats, not just the XML to be consumed or imported by
a tool, but also in CSV format like CIF supports. Maybe each vendor can provide the same info
in readable reports like we see with AV descriptions as well for easy
consumption. For AV companies, please
add the data in your descriptions that match the "Malware Reporting Standard" in
a consistent and obvious way to make it easy for us to consume and use.
Aren’t we just letting the malefactr's, ne`er-do-wellers and malwarians know where and what we are
looking for? Absolutely! If we can squeeze them into a smaller and
smaller target, we win, they lose.
Malware authors will have to spend more time on their warez to avoid
detection. This is a good thing if we can change their behavior and reduce hiding spots.
Something
needs to change, something MUST change if we are to get ahead of malware and
improve our investigation, detection and response capabilities. Support the CIF schema as the start of a
Malware Reporting Standard!
Read the
CIF feed config and schema here:
We will support reporting any malware bits in the format discussed, so should you!
