Characterisation and Application Whitelisting

[Caute_cautim]

All

One of the techniques to counter the advancement of malware within servers, network devices etc is to use "Characterisation"  “characterisation” is a synonym for “unique identifier”.

This is typically applied to an operating system,  programme, library or other programmatic element in the form of a checksum which can be calculated from a “known good” component and stored for comparison should there be any concern that components have been damaged or compromised. 

Forensic methods may also provide characterisation indicators but are likely to require additional levels of expertise.

Application Whitelisting is defined as:

An approach in which all executables and applications are prevented from executing by default, unless explicitly permitted.

So okay, I can apply Characterisation to authorised download sites from vendors and check them with MD5 or SHA512 hashes and I can create baselines for authorised Operating Systems, and other applications etc.

Servers - I can use both Open Source, and Vendors solutions from CFEngine, Carbon Black, Trip Wire for various operating systems - Microsoft Windows uses Applocker etc.

But how does one do the same with Network Devices:

Types traditional network devices - firewall, routers, switches etc

Then how about Virtual network devices, and then think about - how do you apply it to Network Functional Virtualisation?

I am looking for practical suggestions, as a practical framework to manage these.

I have looked at the NIST guidance, and Australian Security Directorate approaches as well.

Suggestions please?

Regards

Caute_cautim

[Caute_cautim]

Hi All

Still working through it, - I did have a response from the policy maker themselves, although they cannot give comment on different vendors, it has caused them to go back to the working table and work through the different scenarios I painted for them.    In summary, traditional networks, Software Derived Networks, Network Functional Virtualisation - each and every category of device regardless of whether it is physical or virtual has to be examined and research conducted as to what individual vendor can provide to ensure that the underlying Operating System can detect changes both externally or in use i.e. by external control means or at command line level.   So basically each case has to be worked through individually and the appropriate risks, threats identified and mitigated. 

I will update upon further research and analysis with examples - as this is going to crop up again and again.

Regards

Caute_cautim

[Caute_cautim]

Update from the Policy authorities:  They cannot comment on individual vendors and associated products, of course, but their suggestion is to categorise each and every Vendor as well as devices types regardless of whether they are physical, virtual, edge or NFVs etc.   Then carefully work through each vendors offerings, and device types and work out whether or not they each of inherent capabilities to detect minute changes to their updates, or patches and examine their capabilities. 

Some vendors with some device types do have some command line capabilities, whereas others require additional external solutions to detect unauthorised changes or attempts to modify updates or patches. 

Obviously, the source is a key area, which can be handled by judicious use of Characterisation as well as confirming the validity of the downloaded update or patch via cryptographic hashing. 

This is turning out to be a journey on a case by case basis.

As a result of my chasing the policy authorities, they are now apparently updating their policy documentation, to provide further clarity as to what is acceptable for Software Defined Network (SDN) environments network devices. 

The fun has started.

Regards

Caute_cautim

[Caute_cautim]

@denbesten

A very good idea indeed - put the problem in their lap, so to speak too. 

Okay now extend this subject, what happens if you have IIoT and IoT embedded gateways as well - that creates another interesting problem too.

Regards

Caute_cautim