RE: [Non-DoD Source] Use Case

["Brule, Joseph M" <jmbrule@radium.ncsc.mil>]

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

 

 

From: efrain@hereuco.com <efrain@hereuco.com>
Sent: Monday, February 10, 2020 1:52 PM
To: 'Considine, Toby' <Toby.Considine@unc.edu>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Subject: RE: [Non-DoD Source] Use Case

 

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

 

From: Considine, Toby <Toby.Considine@unc.edu>
Sent: Monday, February 10, 2020 9:50 AM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; 'efrain@hereuco.com' <efrain@hereuco.com>
Subject: RE: [Non-DoD Source] Use Case

 

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

 

From: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Monday, February 10, 2020 9:44 AM
To: 'efrain@hereuco.com' <efrain@hereuco.com>; Considine, Toby <Toby.Considine@unc.edu>
Subject: RE: [Non-DoD Source] Use Case

 

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….

 

 

From: efrain@hereuco.com <efrain@hereuco.com>
Sent: Friday, February 7, 2020 1:13 PM
To: 'Considine, Toby' <Toby.Considine@unc.edu>
Cc: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Subject: [Non-DoD Source] Use Case

 

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

 

 

 

From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> On Behalf Of Brule, Joseph M
Sent: Friday, February 7, 2020 12:49 PM
To: 'openc2@lists.oasis-open.org' <openc2@lists.oasis-open.org>
Subject: [openc2] OpenC2 Happenings for the Week of 10 February 2020

 

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).         

 

ITEM THREE: Post-plug fest. As reported last week, we had a very successful plug fest / hackathon last week.  We are in the process of documenting and capturing lessons learned. Review the plug fest outcomes page on GitHub. If you were there, contribute your experience.
https://github.com/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/Plugfest-Outcomes.md

 

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.   

Meetings This Week:

Actuator Profile SC
Tuesday, 11 February at 13:00 EST
Meeting link: https://meet.lucidmeetings.com/meeting/241586  


Sent on behalf of the TC Co-Chairs,

 

Joe Brule

'Adnius ad retinedam puritem noster peciosus corporalis fluidorum…'