topic Re: Characterisation and Application Whitelisting in Tech Talk

Characterisation and Application Whitelisting

Caute_cautim — Wed, 19 Sep 2018 22:35:38 GMT

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

Re: Characterisation and Application Whitelisting

rslade — Thu, 20 Sep 2018 00:40:40 GMT

> Caute_cautim (Contributor III) posted a new topic in Tech Talk on 09-19-2018

> 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â€.

Another name for it is signature, and it is used in a wide variety of applications in security.

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

Checksum, CRC, parity bit, hash, signed hash, or even just "existence at a known good state." Change detection was one of the original three antiviral technologies Fred Cohen identified in his original work back in 1983. As well as change detection, it was often known as integrity checking, although I always felt that name promised more than it actually delivered. (See "Authenticode.")

Despite the name, I always felt Integrity Master was a very effective change detection program for applications. My favourite, though, was DiskSecure, which checked the operating system and initial load, was extremely simple, and worked to secure the platform in a wide variety of dangerous situations. (It once saved my bacon when I was reviewing a not very good antivirus and security program.)

> 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:

Basically, on every device you have to start with a trusted platform (a realistically trusted platform, not just something with "TP" in the name), and do the initial check, and subsequent checks, locally. This can be backed up across the net for reporting and comparison for additional security, but you do have to engage additional safeguards to secure the communications.

Microsoft once tried to do it the quick and cheap way with Authenticode. Authenticode used digital signing (by the author) of code, but a) didn't actually guarantee that the code was safe (see "Internet Exploder"), and b) didn't make any provision for certificate revocation. By the time Microsoft lost two keys signing key certificates Authenticode was already seen as weak, and thereafter lost all credibility.

> 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?

Well, note as above.

Re: Characterisation and Application Whitelisting

Caute_cautim — Thu, 20 Sep 2018 00:52:04 GMT

HI @rslade

Thank you for the historical perspective, however, my research points to for example and not citing vendors in particular, but their approaches: I am actively researching solutions at the moment - hence the thread.

1) Juniper has a command line enhancement, tied together with Skytap due to the Intel Spectre and Meltdown issues, which is quite imaginative - but checking whether this is actually sufficient for Application Whitelisting validation purposes.

2) Cisco has Meraki and Umbrella approaches, which means additional services to be applied.

And this is for starters, so looking for good practical suggestions.

Regards

Caute_cautim

Re: Characterisation and Application Whitelisting

rslade — Thu, 20 Sep 2018 01:31:00 GMT

> Caute_cautim (Contributor III) mentioned you in a post! Join the conversation

> I am actively researching solutions at the moment - hence the
> thread. 1) Juniper has a command line enhancement, tied together with
> Skytap due to the Intel Spectre and Meltdown issues, which is quite imaginative
> - but checking whether this is actually sufficient for Application Whitelisting
> validation purposes.

If you are worried about Spectre and Meltdown, the trusted platform is already
busted. (See above.) *Nothing* is going to fix that over the net, particularly not
a mere "command line enhancement." If they are trying to tell you that it will,
they are lying to you.

(Q - What is the difference between a computer salesman and a used car salesman?
A - A used car salesman knows when he is lying to you.)

====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
Buying the right computer and getting it to work properly is no
more complicated than building a nuclear reactor from wristwatch
parts in a darkened room using only your teeth. - Dave Barry
victoria.tc.ca/techrev/rms.htm http://www.infosecbc.org/links
http://blogs.securiteam.com/index.php/archives/author/p1/
http://twitter.com/rslade

Re: Characterisation and Application Whitelisting

Caute_cautim — Thu, 20 Sep 2018 01:48:20 GMT

You are a joy to behold: @rslade Okay I have a scenario in which to prove to an auditor the Application Whitelisting has been applied to Network Devices to satisfy a government mandated control.

No sales, just plain commonsense approach required to satisfy the auditor, against the mandated control.

What is a practical means to do this given my original scenario.

Cheers

Caute_cautim

Re: Caute_cautim mentioned you in (ISC)Â² Community

rslade — Thu, 20 Sep 2018 17:22:00 GMT

> Caute_cautim (Contributor III) mentioned you in a post! Join the conversation

> I have a scenario in which to prove to an
> auditor the Application Whitelisting has been applied to Network Devices to
> satisfy a government mandated control. No sales, just plain commonsense
> approach required to satisfy the auditor, against the mandated control. What
> is a practical means to do this given my original scenario.

Oh, well, yeah. As long as it's just a government mandated control, and not a real
safeguard, then all you have to do is make sure you can bafflegab the auditor and
you're laughing ...

(And, if serious, just follow the instructions in my first response.)

====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
The optimist sees the Klein bottle as half full;
the pessimist sees the Klein bottle as half empty;
the topologist wants to know why you are wasting that stuff
trying to put it *into* a Klein bottle. - rms
victoria.tc.ca/techrev/rms.htm http://www.infosecbc.org/links
http://blogs.securiteam.com/index.php/archives/author/p1/
http://twitter.com/rslade

Re: Caute_cautim mentioned you in (ISC)Â² Community

Caute_cautim — Thu, 20 Sep 2018 20:33:08 GMT

Okay I will work through this as solution design, and report back on my findings.

I think others will have similar experiences in the future, so it could act as a good reference.

Regards

Caute_cautim

Re: Characterisation and Application Whitelisting

denbesten — Thu, 20 Sep 2018 21:09:46 GMT

I have a scenario in which to prove to an auditor the Application White-listing has been applied to Network Devices to satisfy a government mandated control.

Perhaps the auditor is equating "white-listing" with validating against a list of "authorized applications/versions". Maybe you could gather the output of "show version" from each router and demonstrate that the operating system version is within your allowed range.

In other words, you would be demonstrating effectiveness of your patching program as opposed to looking for indicators of compromise.

Re: Characterisation and Application Whitelisting

Caute_cautim — Thu, 20 Sep 2018 21:25:08 GMT

@denbestenSome good points: This is the public linkage to the New Zealand Government policy, it is online.

https://www.nzism.gcsb.govt.nz/

If you do a search on Application Whitelisting, up pops the required controls.

14.2.4.C.01 Agencies SHOULD implement application whitelisting as part of the SOE for workstations, servers and any other network device.

They relate it to the Standard Operating Environment (SOE) - glossary calls it:

A standardised build of an operating system and associated software that is deployed on multiple devices. An SOE can be applied to servers, workstations, laptops and mobile devices.

Now don't fall into the trap of thinking that SHOULD is "optional", it means recommended practice.

However, because it is online, they tend to update on the fly from time to time.

I have asked the authority what is acceptable for a network device - awaiting a response.

I will check with the Australian equivalent to see what their interpretation is as well for cross reference purposes.

This is a work in progress.

Regards

Caute_Cautim

Re: Characterisation and Application Whitelisting

denbesten — Fri, 21 Sep 2018 01:16:44 GMT

If your network devices are supplied by one of the "big guys" that routinely play in the enterprise market (Cisco, Juniper, Palo Alto, Checkpoint, etc), you might also consider discussing the concern with your sales rep or their sales engineer.

Re: Characterisation and Application Whitelisting

Caute_cautim — Sun, 07 Oct 2018 20:06:18 GMT

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

Re: Characterisation and Application Whitelisting

Caute_cautim — Mon, 08 Oct 2018 20:18:08 GMT

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

Re: Characterisation and Application Whitelisting

Caute_cautim — Thu, 18 Oct 2018 19:49:39 GMT

@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