Lang Subcommittee,
One of the items that came up at the plug fest was a need to add a new action known as âuploadâ. Please note that this email chain initially had two people who
were at the plug fest (but are not members) so I removed them from the chain and submitting the discussion to the lang subcommittee
The basic scenario is: We need to have a new action to accommodate the use case where we need to determine whether or not a file is malicious. As of now, an
action to upload the file to be scanned does not exist. Upload would also be a useful action for malware analysis products that need to have new files of known malice uploaded to augment its machine learning procedures.
The proposed scenario is as follows:
UPLOAD (file to some server)
SCAN (the file in question)
QUERY (for the results of the scan)
The following is only my opinion and should carry very little weight. I would rather defer to the malware analytic SMEâs, but if nothing else, maybe this will
stimulate a dialogue.
BACKGROUND
At the language level, OpenC2 is an abstraction. The OpenC2 command (ACTION & TARGET) has a syntax, has semantics associated with it and is at a level to unambiguously
communicate the effect, but does not go into any specifics.
At the actuator profile level, OpenC2 is put into the context of a particular function. One of the reasons for this approach was to enable distributing the function
specific complexity and nuances to the actuator profiles.
MY CONCLUSION:
I think SCAN FILE <malware analytic profile> means that the orchestrator wants to know whether or not some file is benign or malicious so it would be normal
to return the results of that scan.
Obviously the actuator needs to get a hold of the file somehow,
One approach (truth in advertising, my preferred approach) is to send the SCAN FILE <actuator> <one or more arguments telling the actuator to look there for the
file, the file is attached or whatever>
Another approach is simply have the orchestrator send each and every step.
I think breaking out the command into individual steps adds a layer of complexity and sophistication to the orchestrator that we just donât need. If the actuator
sends a schema (BTW, we really should have a âquery features schemaâ command but that is a discussion for another day) then the orchestrator KNOWS what the actuator can and cannot do and what command arguments may or may not be present. If we break it out
into individual steps, then to achieve the effect of getting an unknown file scanned requires the orchestrator to have a-priori knowledge of some sort of sequence of independent commands into some sort of rudimentary course of action that would not be easily
communicated via an exchange of a schema and may have actuator specific subtleties.
SECOND ISSUE
UPLOAD FILE <malware analytic profile> for purposes of updating the machine learning can logically be handled with an UPDATE (I think)
THIRD ISSUE
QUERY HASH <malware analytic profile> to me means that the analysis was already done and we are just making a query on known information.
Thoughts? Does this make sense?
VR
Joe B
Hi Joe,
The challenge during Plugfest was making it easy for participants to send their own data to the BluVector sensor for analysis given that OpenC2 does not support this action today. Our
workaround was fine for the first Plugfest, but in practice it would be ideal for the specification to support the ability to transfer data directly to the sensor. Part of the work may exist at the transfer specification level, as the producer and consumer
have to agree on how the data is posted.
Efrain and I chatted about splitting this into multiple actions:
-
âuploadâ action handles the file transfer
-
âscanâ triggers analysis
-
âqueryâ looks up the results
The upload action could be used as a generic action for moving data and satisfy a variety of interesting use cases.
Mike
Efrain,
I will do some more digging. I know there were more email chatter about this topic, but my email has experienced the second law of thermodynamics and is in a
positive state of entropy.
I took the liberty of CCIng the BluVector guys so they can step in to correct any errors on my part.
Here is the gist of the conversation as I recall:
There are (at least) two scenarios where the BluVector needs to be able to do an upload.
CASE ONE: The BluVector will scan a file then it will return a probability of the file being malicious (or benign). Before you can do the scan, the file in
question has to be uploaded first. My response was along the lines that OpenC2 is at a higher level of abstraction and we are striving for concise effects based communications, i.e. it is not necessary nor desirable to delimit each step. I suggested a SCAN
FILE <with an arg that indicates where to pull the file or whatever>. What goes on under the covers of the BluVector is left to the person creating the interface south of the OpenC2 interface.
CASE TWO: The BluVector is a really cool tool. What they do is that have defined thousands of âvectorsâ, then they have a repository of known malicious and
know benign files. They analyze the files in the context of the vector space (probably use a variant of a Bayesian classifier). If you present a completely unknown file to the tool, then BluVector will compare the analysis with the known benign and malicious
and come up with a probability.
Soooooo, in the context of OpenC2, this brings up the need for an âuploadâ action because they need to upload more known benign and/or malicious files. Based
on the discussions I had, I saw the pre-existing âupdateâ action to be appropriate
I think the BluVector guys were OK with that, what is weird is I am not seeing Efrain on the email chainâ
Mike, Raj,
Was that an accurate capture?
VR
Joe Brule
Thanks for the input Joe. I think the âscanâ action as youâve described it should work fine for this use case.
I will publish a brief âhow-toâ sheet for anyone interested in interfacing with BluVector. Weâll have no problem modifying our implementation on the fly during the event if we want to
make any changes. Publishing a new OpenC2 interface on the sensor can be done very quickly.
Iâll have something to share with the broader group tomorrow.
Thanks,
Mike
Really cool and thank you!
In the context of a âuploadâ action, this is my opinion (therefore worth nothing because you know your product a heck of a lot better than I do) but I would
probably just use âScan fileâ and define a command argument within the context of your actuator that indicates the âscan fileâ includes uploading it first.
OpenC2 is an abstraction and somewhat high level, so not sure I see the advantage of delimiting each step (i.e. I do not see a big problem with a compound action)
In the context of the BluVector, I think you are envisioning a âupload fileâ followed by âscan fileâ and the bluvector returns the probability of malice. I donât
see a significant problem with âscan fileâ including multiple steps under the covers.
My two cents, but will be a good discussion
VR
Joe B
Yes I will send out details to the alias this afternoon. BluVector has implemented the âqueryâ action for file hashes. I may propose a new âuploadâ action that would allow vendors to post data to a sensor for scanning. The OpenC2 spec does not appear to support
this functionality today. The âscanâ action requires the target to already be on the system.
Mr. Myers,
Have a request of you if you feel comfortable doing so. Will you send to the whole plug fest alias the commands and responses you have, even if it is still a work in progress? ( openc2-plugfest-2019@lists.oasis-open.org )
My logic, or lack thereof is along the lines of: BluVector has an actuator responding to a query. One of the other participants is an orchestrator vendor who sees what you are doing and decides they will send the command to the BluVector and see what happens.
Another vendor has a scenario that needs malware analysis and sees the BluVector.
I hate to bother you, but would like to get people seeing what other people got and it is not my place to tell others.
Thoughts?
VR
Joe Brule
Hi Joe,
BluVector will respond to âquery file hashâ and âscan file,â but I will need to investigate âscan directory.â That might be a stretch goal.
We will just need Internet connectivity with access to our VPN. The firewall was configured for RPE5 earlier this year and I can provide the same protocol/port info for this event.
We will only support HTTPS for this exercise.
Thanks,
Mike
Mike, Raj,
I am in the process of summarizing the commands/ responses that will be available at the Plug Fest. (getting ready for next Thursday meeting)
Am I correct in:
-
Hereuco will generate the commands and that the BluVector will respond to a âquery file hashâ and a âscan directory | fileâ?
-
Are you thinking of any others?
-
All you will need is internet connectivity? That is, you do not require any rack space, additional power, cooling etc.
-
Your transfer protocol will be HTTPS? Are you considering other protocols such as ZeroMQ, MQTT or others?
Efrain,
I know you have the command generator for BluVector and your own actuators and I know your powerwall will respond to queries. Am I missing any other commands you were sending to the powerwall?
Thank you and Happy New year!
VR
Joe Brule
Joe,
I am currently working on implementing a module installable on a BluVector sensor that will process the âqueryâ and âscanâ OpenC2 commands. Iâll be using Efrainâs OpenC2 command gen tool for testing.
We have sent an NDA to Efrain in case we want to loop him into the testing process. With an NDA in place, we would be able to grant him direct access to a BluVector sensor.
Thanks and happy holidays,
Mike
Mike Myers
Director â Threat Intelligence
BluVectorÂ,
A Comcast Company
<image001.jpg>
I wanted to touch bases with you to make sure nothing falls through the proverbial cracks. Recall that we had a discussion about the OpenC2 Plug Fest and if I heard correctly, I think that you were going to work
with Efrain to implement a command to query on a hash and another command to submit a file to BluVector to determine the probability of the file being benign or malicious?
Have you been able to work with Efrain?
Thank you and happy holidays!