Efrain,
I changed the subject line, added the AP SC email distro and CCed David Girard. (He is a trend micro guy and they are working on a FAM)
Being able to send the file to the analytic seems logical to me, but to be blunt, the product vendors and the people who work with FAM every day can answer the question better than I can.
All,
The gist of Efrainâs question (read the chain to make sure I do not mischaracterize) is; should we have openc2 send the file to be scanned as a part of the command?
My two cents (with all of my normal disclaimers):
 Sounds
logical to me, but I can see why some people might argue against the notion.
 Is
there a concern of loading the C2 channel? Bandwidth is not an issue for the majority of use cases, but there is an appeal for really concise messages if you have a hostile RF environment during a war.
 What
are the state of the art malware scanners doing today? Do you send the program the file or do you simply send it the path to the file and the software pulls it at its leisure? Or can you do either depending on the product or option you select? What is preferred?
 If
it turns out that the scanner wants the file to be analyzed sent to them, what is the best way to do it? You send it as a binary? An asci? Do you set up an SSH or use HTTPS?
I just reread this and realize I gave no useful information to Efrain. Sorry manâ. Will somebody else step in?
VR
Joe B
Toby, Joe,
First, I didnât totally understand what you were saying with the military reference but Iâll respond with my thoughts. I like Joeâs suggestion of the SCAN action with file and an argument to specify that the file contents are included or referenced
from somewhere else. The uploading of a file and the referencing of a file in a remote location to be retrieved by the actuating device are useful for a reputation lookup. A reputation system wonât necessarily have the reputation scores for all files already,
so it should support an upload mechanism for the orchestratorâs to use. Having the ability to send the actual file to request a reputation scan sounds useful to me. Does it not sound within the realm of OpenC2?
Feel free to forward to whomever you like.
Cheers,
Efrain
I agree.
The essence of OpenC2 is what other parts of DOD call special forces mode.
Take Out Bad Guy
Donât tell me whether it is by knife or garrotte or drone or telling his cousin who has long hated him where he lives.
In openC2
The head informs the body that this file is bad
The body deletes/blocks/searches/prevents network transmission/quarantines and examines as it is capable.
tc
Efrain, Toby,
I hesitate to offer technical suggestions butâ I would suggest a command argument in the malware profile rather than cook up another action.
Here is my logic or lack thereof:
-
The SCAN <target> action in the context of the file anti-malware (FAM) profile has the effect of taking some target <file hash, a single file, a directory of files or whatever> and do some sort of whatever and the actuator returns a benign or malicious result.
-
The effect is SCAN <target>
-
In the context of a FAM, the file may need to be uploaded to the malware scanner, the malware scanner may need to do a remote scan on some server, the malware scanner may do a simple lookup, I donât know, could be one of many things.
-
The point I am trying to make is that the effect is still SCAN <target>, the profile (and its subsequent arguments) puts it in context.
-
Requiring multiple commands (some upload file followed by scan the file) seems like we are requiring the orchestrator to get a-priori knowledge of a sequence of steps to prepare for the effect we want. If there are common âpre-stepsâ for the FAM to do a scan,
then does it make sense to define that in the actuator profile? And leave the commands from the orchestrator concise?
-
How the file is presented to the actuator is a function of the context of the actuator.
Logical?
There is a nuance here that we may need to cross check with the BluVector guys. It is my understanding that BluVector has known malicious and known benign files that it breaks up into a crap-ton of vectors.
An unknown is compared and malice or benign is determined by how the unknown vectors align with the known benign and malicious vectors.
I bring this up because some sort of file upload action is probably not needed for BluVector. We could probably use âUPDATEâ to distinguish it from a new action (if we go that way) for purposes of uploading an
unknown for analysis
VR
Joe B
Misc comment: I would like to CC the actuator profile subcommittee email alias, but I will not do that unless Efrain explicitly says it is OK to do so. More eyes looking at it seems good, but forwarding Efrainâs
email without permission seems badâ.
Hello Toby,
Iâve helped Bluvector behind the scenes answering their questions regarding OpenC2 during the build up to the plugfest and one of the OpenC2 use cases that BluVector AND Google, at the plugfest, brought up is file upload. I donât know if you
remember, but at the plugfest I built a prototype query file hash to query both BluVector and Google. I published this code to my github:
https://github.com/netcoredor/OpenC2-FileQuery-PoC The
next logical step to demonstrate OpenC2 compatibility across these two vendors is to get a file upload for scanning done.
Iâm emailing to bring up the use case of uploading a file to an OpenC2 consumer. Iâm happy to begin experimenting on this command but Iâm having a hard time determining which command to use from the list of available actions and targets in OpenC2. Iâm hoping
to bring this up at the next OpenC2 language TC meeting if possible.
What format should the file object be? Binary? Hex? ASCII encoding? I have no idea. But Iâm guessing we donât want to rely on the HTTP application/zip type for transfer since it should be supportable by other transports. Do I simply add a new suggestion for
a OpenC2 action/target combo?
My 10 cents,
Efrain
OpenC2 Technical Committee,
Our Executive Secretary (Dave Lemire) is unavailable for this weekâs happenings email. I will try to meet his standard of excellence, but donât get your hopes up. Dave will return next week.
Before we start the normal happenings:
Thank you for your continued support of this Technical Committee. Our first Plug Fest was quite successful and the fact that over 2/3 of the participants were not members of this TC indicates that OpenC2
is in fact generating a lot of interest. Realization of wider awareness and interest in this suite of specifications is rewarding. Now it is even more important to remain vigilant and responsive.
As a direct result of the OpenC2 Plug Fest, four companies and an individual are in dialogue with OASIS regarding membership so that they can join the OpenC2 Technical Committee. We are anticipating new
OpenC2 members in the near future, so now is an opportunity for improvement. Please send your feedback and suggestions. Should we improve the Happenings? Should we discontinue the Happenings and pursue another mechanism? Is there a hybrid approach? Please
send your suggestions to Dave Lemire.
And now for our normal Happeningsâ
===================================== tear line ===================================
ITEMS ONE AND TWO:
-
Subcommittee Reorganization. At the next TC meeting, we will issue a call for objections
to stand up a new subcommittee and the current Language Subcommittee and Implementation Consideration Subcommittee will transfer their efforts to the new subcommittee. The Actuator Profile Subcommittee will continue as it is currently operating. To date,
there have been no objections to the proposed way forward. If you have comments or objections to the proposed way forward, please let them be known promptly because it impacts theâ
-
Pending Elections. The TC will conduct elections in March for TC co-chair and one
co-chair for each subcommittee. Nominations for the co-chair are currently open and will remain open until the March TC meeting. Please consider nominating yourself or a colleague for the OpenC2 Technical Committee co-chair, Actuator Profile Subcommitte co-chair
and/or other Subcommittee co-chair (depending on the outcome of the call for objections).
Regardless of whether or not you attended the Plug Fest, letâs find ways to improve our suite of specifications, which leads us toâ
ITEM FOUR: A call for post 1.0 Participation. Version 1.0 of the specifications have been posted, approved, announced and we are seeing implementations. Letâs take advantage of the momentum.
-
Do you have a product or service that's a candidate for producing / consuming OpenC2 commands and responses? Please consider sharing your Custom Actuator Profile or Proposed Committee specification. Contact
the AP-SC co-chairs (Alex Everett and Dave Kemp).
-
We are seeing interest in augmenting the HTTPS transfer specification and other message fabrics. Is there a message fabric that is more suitable for your cyber-ecosystem? Share your proposed key management,
transport solutions and other implementation considerations with the IC-SC co-chairs (Dave Lemire and Michelle Barry)
-
Do you need OpenC2 to do more? Do you have a use case or scenario that we have not considered? Please inform Toby Considine of your use cases and architectural concerns.
Joe Brule
'Adnius ad retinedam puritem noster peciosus corporalis fluidorumâ'