Sponsored Content
Full Discussion: Fake MicroSoft calls
Special Forums Cybersecurity Fake MicroSoft calls Post 303011432 by Neo on Thursday 18th of January 2018 08:17:32 AM
Old 01-18-2018
I recall VoIP vulnerabilities over the years and for many years.

On another note, it is always important to keep in mind that (IT) RISK is the intersection of VULNERABILITY, THREAT & CRITICALITY.

So, even if there is a VULNERABILITY, if there is no real THREAT or CRITICALITY, then RISK is LOW.

For example, for someone who uses VoIP and is not a high profile person or spy or criminal etc who has THREATS and if a VULNERABILITY is exploited, it does not do critical harm (in the case of VoIP threats for most people who use VoIP daily), then the RISK is low.

I've been aware of possible VoIP exploits for many years, but it does not stop me from using the myriad technologies that use VoIP. This especially applies to VoIP technologies which are encrypted. LINE, What's App and I believe Skype are all encrypted and so exploiting these VoIP vulnerabilities are non trivial, as I recall, and so most users who use encrypted VoIP are not at high RISK.

There is also the RISK MITIGATION model, which combines TECHNICAL (LOGICAL) CONTROLS, PHYSICAL CONTROLS AND ADMINISTRATIVE CONTROLS, should be considered as well

Encrypting a VoIP channel is a TECHNICAL CONTROL and having a policy whereas HIGHLY SENSITIVE USERS do not use these apps unless approved is an ADMINISTRATIVE CONTROL.

It is important to keep in mind that RISK MANAGEMENT and RISK MITIGATION is a multidimensional and multifaceted approach, so VULNERABILITIES must be viewed in context to the THREAT and CRITICALITY; and RISK MITIGATION must be viewed in terms of RISK and the "best" combination of controls (ADMIN, TECH, PHYSICAL) based on RISK (and this implies budget as well).

Cheers.
This User Gave Thanks to Neo For This Post:
 

2 More Discussions You Might Find Interesting

1. IP Networking

Identification of data calls & voice calls

Is there any facility to filter/identify the data calls and voice calls coming throug modem? OR Can we get the data or voice calls information through a script(preferably C Kermit)? (0 Replies)
Discussion started by: pcsaji
0 Replies

2. Windows & DOS: Issues & Discussions

Microsoft Powerpoint 2003 stops working after 12 April 2011 Microsoft Updates

For the benefit of the community this is a widespread worldwide problem affecting multiple versions of Microsoft Windows. Powerpoint erroneously reports Powerpoint presentation damaged and then often hangs. Until Microsoft sort this out, try removing Powerpoint security update KB 2464588... (0 Replies)
Discussion started by: methyl
0 Replies
Courier::Filter::Module::FakeDate(3pm)			User Contributed Perl Documentation		    Courier::Filter::Module::FakeDate(3pm)

NAME
Courier::Filter::Module::FakeDate - Fake "Date:" message header filter module for the Courier::Filter framework SYNOPSIS
use Courier::Filter::Module::FakeDate; my $module = Courier::Filter::Module::Header->new( forward_tolerance => { # years, months, weeks, days, hours, minutes, seconds hours => 2 }, backward_tolerance => { # years, months, weeks, days, hours, minutes, seconds days => 5 }, ignore_unparseable => 0, logger => $logger, inverse => 0, trusting => 0, testing => 0, debugging => 0 ); my $filter = Courier::Filter->new( ... modules => [ $module ], ... ); DESCRIPTION
This class is a filter module class for use with Courier::Filter. It matches a message if it has a "Date" header field that lies too far in the future or the past, relative to the local system's time. If the message has a "Resent-Date" header field (see RFC 2822, 3.6.6), that one is examined instead, because the message could simply be an old one that has recently been re-sent, which is perfectly legitimate behavior. In the case of a match, the response tells the sender that their "Date" header is implausible and that they should check their clock. Note: Times in different time zones are compared correctly. Note: When using this filter module, it is essential that the local system's own clock is set correctly, or there will be an increased risk of legitimate messages getting rejected. Constructor The following constructor is provided: new(%options): returns Courier::Filter::Module::FakeDate Creates a new FakeDate filter module. %options is a list of key/value pairs representing any of the following options: forward_tolerance backward_tolerance The maximum durations by which a message's "Date" or "Resent-Date" header may diverge into the future and the past, respectively, from the local system's time. Each duration must be specified as a hash-ref containing one or more time units and their respective quantity/ies, just as specified by DateTime::Duration. "forward_tolerance" defaults to 2 hours. "backward_tolerance" defaults to 5 days to account for transmission delays. For example: forward_tolerance => { hours => 4 }, backward_tolerance => { days => 1, hours => 12 } ignore_unparseable A boolean value controlling whether messages whose "Date" or "Resent-Date" header does not loosely conform to RFCs 822 or 2822 should be ignored (true) or matched (false). Defaults to false. All options of the Courier::Filter::Module constructor are also supported. Please see "new" in Courier::Filter::Module for their descriptions. Instance methods See "Instance methods" in Courier::Filter::Module for a description of the provided instance methods. SEE ALSO
Courier::Filter::Module, Courier::Filter::Overview. For AVAILABILITY, SUPPORT, and LICENSE information, see Courier::Filter::Overview. AUTHOR
Julian Mehnle <julian@mehnle.net> perl v5.14.2 2011-12-27 Courier::Filter::Module::FakeDate(3pm)
All times are GMT -4. The time now is 04:30 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy