Re: [Fed-Talk] Death of signatures
Re: [Fed-Talk] Death of signatures
- Subject: Re: [Fed-Talk] Death of signatures
- From: Will Ross <email@hidden>
- Date: Tue, 14 Feb 2012 11:44:04 -0500
I think what William is trying to say is that instead of an explicit allow/deny ruleset
(like SELinux or the sandboxing in recent releases of OS X), we're lacking in adaptive
systems. A very primitive example of one of these systems is the application level
firewall included since 10.5. It can be set to allow incoming network access to
signed applications automatically, or the standard explicit allow/deny set when it first
tries opening a listening socket. An better system would be one that notices that your
listening program normally receives connections from itself, or maybe just machines
on local subnets. But if the firewall notices that connections are now coming in from
remote addresses it could then try warning the user somehow, as it's likely something
has changed.
-Will
On Feb 14, 2012, at 10:58 AM, David Mueller wrote:
> What you describe sounds a lot like what SELinux does.
>
> - David
>
>
> On 2/14/12 4:04 AM, "William Cerniuk" <email@hidden> wrote:
>
>> Honestly I have not been following this closely but has the topic of app
>> signatures come up?
>>
>> The issue with viruses is that they are developed rapidly and some developed
>> to intentionally mutate. Like a real biological virus, it make the computer
>> virus much harder to track and thwart.
>>
>> Think of this in biological terms. Imagine having to identify unknown and
>> un-discovered viruses with anti-viral compounds. Very much like a broad
>> spectrum antibiotic, the current antivirus software operates as a wide barrier
>> to 'infection".
>>
>> What we lack are not indicators of infection but tracking indicators of
>> health. From the biological side, we tell the doc we don't feel normal, don't
>> feel goods, something is wrong. This frequently happens well before the
>> infection is serious. The sillcon corrilary is tracking normal application
>> and user behavior.
>>
>> For example, we know that Microsoft Word should not be accessing the kernel
>> extensions. We also know that MS Word should not make any network connections
>> outside of operating system services. MS Word should not be probing the
>> network, pinging other machines in the local subnet, accessing any network
>> connection short of update services and user initiated links in documents. If
>> it does start doing this we would say it is not feeling well or potentially
>> has a cold.
>>
>> In this way an outbreak of a new virus could be detected. If the software that
>> acted as the 'nurse' in this case reported the problem to the 'doctor' (the
>> central virus detection database') outbreaks could be detected and thwarted in
>> their very early stages.
>>
>> From a "truth in lending" perspective, this is from a conversation I had with
>> a friend in the antivirus business. They call this feature "heuristic
>> detection". It establishes a baseline of any app's activity and then when the
>> app starts operating out of bounds, the user is flagged with a warning and the
>> ability to stop the app from performing the out of bounds activity.
>>
>> Best, Wm.
>>
>>
>> On Feb 13, 2012, at 4:16 PM, Todd Heberlein <email@hidden> wrote:
>>
>>>
>>> On Feb 12, 2012, at 6:21 PM, Joel Esler wrote:
>>>
>>>> So what's new?
>>>
>>> That it is called out specifically at the budget level.
>>>
>>> For about 15 years starting in 1988 I received gov't funding for IDS (DOE,
>>> DARPA, AFRL, ...), and none of them wanted work done on signatures. They were
>>> always looking for solutions that could address unknown vulnerabilities &
>>> attacks (and insiders). So nothing knew there. I've just never seen it
>>> escalate so high on the budgetary wish list.
>>>
>>> Over the years the challenge that I could see was that solutions that worked
>>> well in researchers' hands running in labs struggled in operational
>>> environments.
>>>
>>> Todd
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Fed-talk mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Fed-talk mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Fed-talk mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden