This article is contributed. See the original author and article here.
Cisco has released security updates to address vulnerabilities in Cisco Small Business RV160, RV260, RV340, and RV345 Series Routers. A remote attacker could exploit some of these vulnerabilities to take control of an affected system. For updates addressing lower severity vulnerabilities, see the Cisco Security Advisories page.
CISA encourages users and administrators to review Cisco advisory cisco-sa-smb-mult-vuln-KA9PK6D and apply the necessary updates.
This article is contributed. See the original author and article here.
The SMTP protocol isn’t secure and wasn’t designed to be. Email sent in the early days of the Internet were the digital equivalent of sending a postcard through the postal system. Eventually, Transport Layer Security (TLS) encryption was added to protect SMTP communications. But to maintain backward compatibility, it was never made compulsory and even today it’s used only opportunistically by senders.
TLS uses certificates for encryption, but they aren’t used for verifying the identity of the destination server. This exposes SMTP connections to DNS tampering that can redirect connections to an attacker’s server. Senders have no way to confirm that destination server is the intended email server. Even worse, after intercepting traffic, a savvy attacker can relay it to the intended destination, and neither the sender nor the recipient would be aware that a man-in-the-middle attack ever took place.
The SMTP MTA Strict Transport Security (MTA-STS) standard was developed to ensure that TLS is always used, and to provide a way to for sending servers to refuse to deliver messages to servers that don’t support TLS and have a trusted certificate. The MTA-STS standard was developed by several email industry companies brought together by the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). We have been validating our implementation and are now pleased to announce support for MTA-STS for all outgoing messages from Exchange Online.
Outbound Protection
All outbound Exchange Online email traffic is covered by this new security feature, and there’s nothing admins need to do to leverage it. Our outbound implementation respects the wishes of the recipient domain owners via their MTA-STS policy. MTA-STS now forms part of the security infrastructure of Exchange Online, and it’s always on (like other core SMTP features).
Inbound Protection
Nothing new is needed from Exchange Online to leverage MTA-STS protection for your own domains. Exchange Online supports TLS1.2 and offers the TLS certificates that are required by the standard. As domain owners ourselves, we secured several of our own domains, including primary domains such as outlook.com, hotmail.com, and live.com. Therefore, we’re now assured that connections from senders who support MTA-STS are much better protected against man-in-the-middle attacks. If a sender does not perform MTA-STS validations, email will still be delivered as normal, and TLS will be used if the sender chooses to use it.
NOTE: Messages will be delivered when only one party supports MTA-STS. For example, when an MTA-STS-protected domain receives a message from a sender domain that doesn’t support MTA-STS, the message is delivered. The message is also delivered when the recipient domain doesn’t support MTA-STS, but the sender domain does. The only scenario where messages aren’t delivered is when both sides are using MTA-STS and MTA-STS validation fails.
How To Adopt MTA-STS
MTA-STS allows a domain to declare support for TLS and communicate the MX record and destination certificate to expect. It also indicates what a sending server should do if there’s a problem. This is done through a combination of a DNS TXT record and a policy file that’s published as an HTTPS web page. The HTTPS-protected policy introduces another security protection that attackers must overcome.
A domain’s MTA-STS TXT record indicates MTA-STS support to a sender, after which the domain’s HTTPS-based MTA-STS policy is retrieved by the sender. The following TXT record is an example that declares support for MTA-STS:
_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20211201000000Z;
A domain’s MTA-STS policy is located at a predefined URL that’s hosted by the domain’s web infrastructure. The URL syntax is https://mta-sts.<domain name>/.well-known/mta-sts.txt. For example, Microsoft.com’s policy is found at: https://mta-sts.microsoft.com/.well-known/mta-sts.txt
Any customers whose MX records point directly to Exchange Online can use this same policy. The unique, required information in the policy is the MX record that points to Exchange Online, and the same certificate is shared by Exchange Online customers.
To be protected by MTA-STS, a domain owner needs to create the DNS TXT domain record and host the policy file at the required HTTPS URL with a valid certificate that contains their domain. Details about MTA-STS are available in RFC 8461.
Staying Informed Through TLS-RPT Reports
Accompanying MTA-STS is an extremely useful industry specification that outlines a standard mechanism to allow email services to report sending issues that occur when sending to a specific domain. This is the first time a channel is available for domain owners to get direct reports of actual issues that senders encounter when sending email to the domain. This reporting mechanism can avoid the need for senders to report issues related to sending email to your domain.
The TLS-RPT standard provides reporting for MTA-STS (and DANE for SMTP) with a single daily report from each email service that supports it. To receive TLS-RPT reports, a domain owner can create a DNS TXT entry to indicate where they would like to receive reports. For most admins, it means sending the reports to an email address, as shown in the following example:
TXT Record example: _smtp._tls.example.com. 3600 IN TXT TLSRPTv1;rua=mailto:reports@example.com
Email services that send email to your domain and that support both MTA-STS and TLS-RPT send daily reports to the provided email address. Details about TLS-RPT are available in this RFC 8460. Microsoft has started sending TLS-RPT reports to domains that have requested them.
MTA-STS Failures
If an MTA-STS check fails and the domain’s policy is set to enforce, an NDR will be generated and the message will not be sent. The following list describes the errors that might occur due to MTA-STS failures:
Destination server does not support TLS
551 5.7.4 STARTTLS is required by recipient domain’s MTA-STS policy
Destination server does not support TLS 1.2 or above
We try to respect RFCs to the best of our abilities. The goal is to achieve the best interoperability possible. In a small number of scenarios, there may be unexpected behavior, and we’ll do our best to document that behavior.
For example, one difference in behavior involves CNAME records and MX records. Having a CNAME record for an MX record doesn’t comply with the SMTP RFC, but in the interest of successfully sending the email of our customers, we currently resolve CNAMEs to the servers that they point to for message deliveries. For MTA-STS, we’ve taken a stricter approach to supporting the RFC. We do not support CNAMEs when MTA-STS is used. If a domain uses a CNAME and follows the MTA-STS RFC, that domain will fail our MTA-STS checks, and will not receive emails from us. However, it’s possible for a domain to include the final server in their MTA-STS policy and pass our MTA-STS checks, even though that would not strictly follow the MTA-STS RFC.
MTA-STS Vs SMTP DANE
MTA-STS came about because of the slow roll out of DNSSEC to protect the DNS records that are associated with SMTP. MTA-STS can be seen as a lighter-weight mechanism to secure your mail flow. Although MTA-STS offers a much-needed upgrade to current SMTP protections, DANE for SMTP (with the support of DNSSEC) is the gold standard for securing SMTP connections. However, many customers might find MTA-STS good enough for their security needs.
We’ve been working on support for both MTA-STS and DANE for SMTP. At the very least, we encourage customers to secure their domains with MTA-STS. You can use both standards on the same domain at the same time, so customers are free to use both when Exchange Online offers inbound protection using DANE for SMTP by the end of 2022. By supporting both standards, you can account for senders who may support only one method.
Both MTA-STS and DANE require adoption from domain owners on the receiving side and services/servers that send email. We strongly encourage everyone to adopt these standards to improve the overall security of SMTP connections. Currently, we successfully validate connections to over 35K MTA-STS-protected domains, and this number is growing every month.
Future Work
We’re actively working on features that are related to the MTA-STS and DANE for SMTP standards with the goal of making it easier for our customers to make the most of them. We’ll announce these features as they become available.
This article is contributed. See the original author and article here.
The past year has cultivated many personal and professional changes. No person or industry has been untouched. Even field service has embraced seismic changes as a result of the ongoing global pandemic. For many field service organizations, being dispatched to the customer’s location to diagnose and resolve an issue became more complex than ever before. In response, a shift began within field service to less hands-on, more remote, and more dynamic and proactive service operations.
We believe this placement recognizes Microsoft’s continuous investment and authority across our service solution and cloud functionality.
IDC MarketScape vendor analysis model is designed to provide an overview of the competitive fitness of ICT suppliers in a given market. The research methodology utilizes a rigorous scoring methodology based on both qualitative and quantitative criteria that results in a single graphical illustration of each vendor’s position within a given market. The Capabilities score measures vendor product, go-to-market and business execution in the short-term. The Strategy score measures alignment of vendor strategies with customer requirements in a 3-5-year timeframe. Vendor market share is represented by the size of the icons.
Noted capabilities
IDC MarketScape objectively noted the strengths, challenges, and considerations of each vendor. For Microsoft, the IDC MarketScape noted one of our strengths as “The ability to deliver specific capabilities to support the market is critical to rapid adoption and ROI. Customer references also noted that Microsoft’s integration with other enterprise applications and technical capabilities of the application helped speed deployment and achieve value quickly.”
IDC MarketScape also noted “Microsoft’s primary challenge with regard to field service management is with regard to industry-specific innovations. Microsoft has established a culture of innovation around many of its products and highlights service-specific offerings, which demonstrate the future of field service collaboration and execution. However, manufacturers and some service organizations lag behind those in other industries, and companies like Microsoft will need to provide both transformative offerings and incremental innovations that closely align with the risk aversion of the specific subvertical industry.” Fortunately, Microsoft caters to everyone from the intrepid to the risk-averse with both transformative offerings and incremental innovations that closely align with the customer’s palatable level of risk.
The study advised “Manufacturers and service organizations should consider Microsoft when they are looking for an integrated field service product offering that can seamlessly integrate IoT data, remote collaboration, AI, and AR/mixed reality capabilities to enable more predictive and proactive service outcomes. The ability to collaborate in real time and have on-demand insights is transforming the way field service and support can be conducted. Microsoft is helping manufacturers that are on this journey around servitization and the convergence of AI, IoT, and AR in the field.”
And the transformation is occurring in real-time. Take for example, Burckhardt Compression, a global leader in manufacturing and servicing, headquartered in Switzerland. The company builds and services massive compressors weighing up to 240 tons, creating pressure three times higher than at the deepest point in the ocean. This high pressure transforms gas to a liquid state so it has less volume and is transported easier. If the compressor fails, the liquid turns back to gas and the build-up of pressure can be critical for the ship and the crew.
Because maintenance is so critical, Burckhardt Compression had to send a service engineer to wherever the compressor was locatedwhich was time-consuming, resource-intensive, and simply not scalable. To provide support at any location, Burckhardt Compression adopted Microsoft Dynamics 365 Field Service for field service management and Dynamics 365 Remote Assist, a mixed reality application. Now remote service engineers have access to real-time service data and can support the ship’s technicians by engaging in on-demand video chat, providing instruction augmented with a schematic overlay, and creating markups onscreen over the actual compressor. And a case is automatically created in Dynamics 365 Field Service when a call is initiated by Dynamics 365 Remote Assist, and a recording of the repair work is saved.
Burckhardt Compression is serving customers faster by eliminating travel time and sharing expert knowledge across the globe in a matter of minutes increasing trust, safety, and business continuity. Now the company is looking to expand to add non-Burckhardt compressors to its service roster, thereby expanding its market presence and generating additional revenue. Burckhardt Compression is just one of many manufacturing and servicing organizations that have reaped value by deploying Dynamics 365 Field Service and harnessing its capabilities to build stronger, more collaborative, and proactive service delivery.
The bottom line
Many service organizations consist of dispatchers answering service calls, putting customers on hold, asking the same questions repeatedly, while searching for the next available technician to dispatch. This process is inefficient, costly, and unsatisfying to the customer.
The world of field service is changing. Today, service organizations are evolving into profit centers, redefining business models, and creating powerful and fulfilling customer experiencesall supported by leading edge solutions like Dynamics 365 Field Service.
We’re excited to be positioned as an IDC MarketScape Leader and are committed to bringing you the best and most featured field service application available. Depend on the multidimensional capabilities of Dynamics 365 Field Service to help you better personalize customer engagements, improve employee effectiveness, and optimize service operations now and tomorrow.
This article is contributed. See the original author and article here.
Google has released Chrome versions 98.0.4758.80/81/82 for Windows and 98.0.4758.80 for Mac and Linux. These versions address vulnerabilities that an attacker could exploit to take control of an affected system.
CISA encourages users and administrators to review the Chrome Release Note and apply the necessary updates.
This article was originally posted by the FTC. See the original article here.
Taking steps to protect your personal information can help you minimize the risks of identity theft. But what if a thief gets your information anyway? Here are some of the ways thieves might use your stolen information and signs you can look out for.
An identity thief could use your information to get credit or service in your name.
How to spot it: Get your free credit report at AnnualCreditReport.com. Review it for accounts you didn’t open or inquiries you don’t recognize. A new credit card, a personal loan, or a car loan will appear as a new account. A new cell phone plan or utility service — like water, gas, or electric — will show up as an inquiry.
An identity thief could use your credit card or take money out of your bank account.
How to spot it: Check your credit card or bank statement when you get it. Look for purchases or withdrawals you didn’t make.
Bonus advice: Sign up to get text or email alerts from your credit card or bank whenever there’s a new transaction. This could help you spot unauthorized or fraudulent activity on your account.
An identity thief could steal your tax refund or use your Social Security number to work.
How to spot it: A notice from the IRS that there’s more than one tax return filed in your name could be a sign of tax identity theft. So could a notice that you have income from an employer you don’t work for.
An identity thief could use your health insurance to get medical care.
How to spot it: Review your medical bills and Explanation of Benefits statements for services you didn’t get. They could be a sign of medical identity theft.
An identity thief could use your information to file a claim for unemployment benefits.
How to spot it: A notice from your state unemployment office or employer about unemployment benefits that you didn’t apply for could be a sign of fraud.
If you discover any signs that someone is misusing your personal information, find out what to do at IdentityTheft.gov.
And remember to check out our daily free events and webinars with our co-partners during Identity Theft Awareness Week.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments