Post-Quantum Cryptography (PQC) Standardization Process:

    It
has been almost a year and a half since the second round of the NIST PQC
Standardization Process began. After careful consideration, NIST would like to
announce the candidates that will be moving on to the third round. The seven
third-round Finalists are:



Third Round Finalists 

Public-Key
Encryption/KEMs

Classic McEliece
CRYSTALS-KYBER
NTRU
SABER  

Digital
Signatures

CRYSTALS-DILITHIUM
FALCON
Rainbow


In
addition, the following eight candidate algorithms will advance to the third
round:



Alternate Candidates

Public-Key
Encryption/KEMs

BIKE;
FrodoKEM
HQC
NTRU Prime
SIKE  

Digital
Signatures

GeMSS
Picnic
SPHINCS+



    During
the third round, the term “finalist” will refer to the first seven algorithms
listed above, and the terms “alternate” or “alternate candidate” will be used
for the other eight algorithms also advancing. The finalists will continue to
be reviewed for consideration for standardization at the conclusion of the
third round. As CRYSTALS-KYBER, NTRU, and SABER are all structured lattice
schemes, NIST intends to select, at most, one for the standard. The same is
true for the signature schemes CRYSTALS-DILITHIUM and FALCON. In NIST’s current
view, these structured lattice schemes appear to be the most promising
general-purpose algorithms for public-key encryption/KEM and digital signature
schemes.


    For
the eight alternate candidate algorithms being advanced into the third round,
NIST notes that these algorithms may still potentially be standardized,
although that most likely will not occur at the end of the third round. NIST
expects to have a fourth round of evaluation for some of the candidates on this
track. Several of these alternate candidates have worse performance than the
finalists but might be selected for standardization based on a high confidence
in their security. Other candidates have acceptable performance but require
additional analysis or other work to inspire sufficient confidence in their
security or security rationale. In addition, some alternates were selected
based on NIST’s desire for a broader range of hardness assumptions in future
post-quantum security standards, their suitability for targeted use cases, or
their potential for further improvement.


    NIST
would like to thank all of the submission teams for their efforts in this
standardization process. It was not an easy decision to narrow down the
submissions. A detailed description of the decision process and rationale for
selection are available in NIST
Internal Report (NISTIR) 8309, 
Status Report on the Second Round of the NIST Post-Quantum
Cryptography Standardization Process
. It is also
available on the NIST post-quantum webpage, www.nist.gov/pqcrypto.
Questions may be directed to [email protected].
NIST hopes that the teams whose scheme were not selected to advance will
continue to participate by evaluating and analyzing the remaining cryptosystems
along with the cryptographic community at large. These combined efforts are
crucial to the development of NIST’s future post-quantum public-key standards.



    For
the algorithms moving on to the third round, NIST will allow the submission
teams the option of providing updated specifications and implementations (i.e.,
“tweaks”). The deadline for these tweaks will be October 1, 2020. It would be
helpful if submission teams provided NIST with a summary of their expected
changes by August 10, 2020. If any submission team feels that they may not meet
the deadlines, they are strongly encouraged to contact NIST to discuss. NIST
will review the proposed modifications and publish the accepted submissions
shortly afterwards. As a general guideline, NIST expects that any modifications
to the seven finalists will be relatively minor while allowing more latitude to
the eight alternate candidate algorithms. Note, however, that larger changes
may signal that an algorithm is not mature enough for standardization at this
time. More detailed information and guidance will be provided in another
message.



    It
is estimated that this third phase of evaluation and review will last 12-18
months. NIST is planning to hold a 3rd NIST PQC Standardization Conference
in 2021. Obviously, much of the conference details will depend on conditions
relating to the pandemic and have not been finalized. The preliminary Call for
Papers for this conference can be found at www.nist.gov/pqcrypto and
will also be posted to this pqc-forum in another message. The deadline for
submission to the 3rd NIST PQC Conference will likely be sometime around the
end of 2020.



    Note:
These are NIST’s current plans. If new results emerge during the third round
which undermine NIST’s confidence in some of the finalists, NIST may extend the
timeline, or make changes to the process.  If NIST has less serious
concerns specific to a particular finalist and sees the need to continue
evaluating it, NIST may instead defer the decision about standardization for
the affected finalist until the fourth round. 

NISTIR
8309:
https://csrc.nist.gov/publications/detail/nistir/8309/final



NIST
Post-Quantum Cryptography project:
https://www.nist.gov/pqcrypto

CISA Releases New Cyber Essentials Toolkit on Organization-Wide Cybersecurity

    CISA released
its Cyber Essentials Toolkit,
Chapter
2: Your Staff, The Users
. This toolkit is the second in a series of six
toolkits set to be released each month. This chapter follows the release of Chapter 1: Yourself, The Leader
– Drive Cybersecurity Strategy Investment and Culture and CISA Cyber Essentials
in November 2019.


    Chapter 2
emphasizes the importance of the organization as a whole in cybersecurity,
requiring a shift toward a culture of cyber readiness and greater cyber
awareness among staff by providing cyber education, training, and other
resources. Focus areas include, leveraging basic cybersecurity training;
developing a culture of cyber awareness that incentivizes making good choices
online; teaching employees about risks such as phishing and ransomware; and
identifying available training resources from partner organizations.

To learn more
about the Cyber Essentials Toolkits, visit https://go.usa.gov/xfbFN. 

Hacked Data Get Hacked

A security firm based out of St. Louis, Mo. which specializes in collecting breach data from online sources has itself been breached, exposing some 15 billion usernames, passwords, and other personal
information collected from over 8000 website breaches. The breach collector technology called Data Viper, from the cyber threat intelligence firm Night Lion Security, describes its Data Viper product as a “threat intelligence platform designed to provide organizations, investigators and law enforcement with access to the largest collection of private hacker channels, pastes, forums and breached databases on the market.”

    A data breach monitoring service typically scans, collects, analyzes, and presents breach data from a variety of sources including the dark web, paste bin sites, hacker forums, and other locations, then
sells access to this information to concerned parties. The service allows private companies, Law Enforcement, and other organizations to search and monitor for “data of interest”. This is usually account information such as usernames and credentials indicating that an organization has been breached. The service compiles and indexes previously hacked databases in a proprietary backend. Some of this data has already been disclosed and publicly reported, while some of the data corresponds to yet undisclosed security breaches.

    If this data is valuable enough to be offered by cybersecurity firms as a service and subsequently purchased by organizations worried about a compromise or validating a data leak, then it is valuable
to cybercriminals. The very places where much of this data was originally acquired are also where cybercriminals are now reselling the information. The hacker claiming recognition for the breach has ads on the Empire dark web market place selling access to over 8,225 data-bases exfiltrated from the Data Viper service and proof of legitimacy.

     The traditional risk/reward to calculate profit potential versus the effort required to compromise the desired system has swung greatly in the hacker’s favor when targeting threat intelligence platforms. The effort required to compromise one company or information system to gather information from one distinct group or database is essentially a payout of 1:1. That effort can be expended on compromising an information system holding much more.

    At face value the Data Viper breach ratio seems to be on the order of 1:8225 (8,225 databases were exfiltrated). But wait, it’s even greater than that! Not only did the hacker not need to put in the original effort required to compromise these victims but they also absolved them-selves from having to perform all the data collection, processing, management, and warehousing tasks required to make said information consumable. That value-added effort was already undertaken by the company offering the threat intelligence platform.

     In conclusion, the reward is too great for these systems not to be under constant attack, the carrot is too big and some fences too small, creating a huge incentive for cybercriminals.

Sources:

Security Guidelines for Storage Infrastructure: Draft SP 800-209

    Storage
infrastructure—along with compute (encompassing OS and host hardware) and
network infrastructures—is one of the three fundamental pillars of Information
Technology (IT). However, compared to its counterparts, it has received
relatively limited attention when it comes to security, even though data
compromise can have as much negative impact on an enterprise as security
breaches in compute and network infrastructures. 


    In
order to address this gap, NIST is releasing Draft Special Publication (SP) 800-209, Security Guidelines for Storage Infrastructure,
which includes comprehensive security recommendations for storage
infrastructures. The security focus areas covered in this document not only span
those that are common to the entire IT infrastructure—such as physical
security, authentication and authorization, change management, configuration
control, and incident response and recovery—but also those that are specific to
storage infrastructure, such as data protection, isolation, restoration
assurance, and data encryption.


    The public comment period for this document is open through August
31, 2020.
See the publication
details
for a copy of the document and instructions for submitting
comments.



    NOTE:
A call for patent claims is included on page iii of this draft. For additional
information, see the Information
Technology Laboratory (ITL) Patent Policy–Inclusion of Patents in ITL
Publications
.

Project Freta: detecting rootkits and advanced malware, in memory snapshots of live Linux systems

   Project Freta: free service from Microsoft Research for detecting evidence of OS and sensor sabotage, such as rootkits and advanced malware, in memory snapshots of live Linux systems



   Incubated at Microsoft Research, Project Freta is a roadmap toward trusted sensing for the cloud that can allow enterprises to engage in regular, complete discovery sweeps for undetected malware. The project’s namesake, Warsaw’s Freta Street, was the birthplace of Marie Curie, a pioneer of battlefield imaging. While snapshot-based memory forensics is a field now in its second decade, no commercial cloud has yet provided customers the ability to perform full memory audits of thousands of virtual machines (VMs) without intrusive capture mechanisms and a priori forensic readiness. Just as yesteryear’s film cameras and today’s smartphones have similar megapixels but vastly different ease of use and availability, Project Freta intends to automate and democratize VM forensics to a point where every user and every enterprise can sweep volatile memory for unknown malware with the push of a button—no setup required.

Project Freta’s four properties of trusted sensing
1. Detect. No program can:
Detect the presence of a sensor prior to installing itself
2. Hide. No program can:
Reside in an area out of view of the sensor
3. Burn. No program can:
Detect operation of the sensor and erase or modify itself prior to acquisition
4. Sabotage. No program can:
Modify the sensor in a way that can prevent the program’s acquisition

To learn more go here.

Graphics Processing Units in Vulnerable Lane

    In the past, Graphics Processing Unit (GPU) drivers weren’t a typical target for system exploitation, but this has changed in recent years. Many computing applications from desktop to server require more graphics horsepower than ever before and, as such, discrete GPUs are more common than ever. Laptops are even often configured with high-performance GPUs included instead of the basic CPU embedded graphics chipsets of the past. Modern GPUs are highly complicated components requiring complex system drivers to maximize the GPUs capability.

    As system complexity increases continuously, so does the potential for finding a way to exploit the system. This effect is multiplied because GPU drivers usually run in the highest privilege ring of the system, kernel mode. This week, graphics chip maker Nvidia patched its drivers to fix two high security vulnerabilities as well as several lower severity vulnerabilities.

    The first vulnerability patched by Nvidia this week relates to the Nvidia Control Panel component. This software is bundled as part of the Nvidia graphics driver package and allows for adjusting settings related to the graphics subsystem. The vulnerability, assigned CVE-2020-5962, allows for a local attacker to corrupt critical system files, leading to denial of service or escalation of privileges. Little information is available about the vulnerability specifics but systems running this software should be updated to prevent local attacks against the machine.

    CUDA is a subsystem in Nvidia drivers that allows for non-graphics use of the high-performance processing units for machine learning or artificial intelligence programs. These applications benefit greatly from the highly-parallelized nature of graphics hardware and typically use high-end graphics cards for their processing. The second high security vulnerability, CVE-2020-5963, is in the CUDA component of the graphics driver. Again, little information is available about the specifics, but the issue appears to stem from a mistake in the access control security in the Inter Process Communication APIs. This vulnerability could lead to arbitrary code execution from a lower privilege process in the context of a high privilege process.

    Other Nvidia vulnerabilities patched this week are classified as medium severity. CVE-2020-5967 and CVE-2020-5965 appear to be similar vulnerabilities in Linux and Windows respectively, which allow for denial of service to the target system. CVE-2020-5964 and CVE-2020-5966 are exclusive to Windows systems and range in severity from denial of service to arbitrary code execution.
As high-performance GPUs become more common in even basic systems it is important to verify that your drivers are being updated in a timely fashion.

Sources:
       
https://threatpost.com/nvidia-windows-gamers-graphics-driver-bugs/156911/

https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Sources:

Netgear Router Vulnerabilities

National Cyber Awareness System:

06/29/2020 03:44 PM EDT
Original
release date: June 29, 2020

    Multiple Netgear router models contain vulnerabilities that a remote
attacker can exploit to take control of an affected device.

    The Cybersecurity and Infrastructure Security Agency (CISA) encourages users
and administrators to update to the most recent firmware version and to replace
end-of-life devices that are no longer supported with security patches. Given
the increase in telework, CISA
recommends that CISOs consider the risk that these vulnerabilities present to
business networks.
See the following products for additional information.

DNS Vulnerability – CVSS – Score of 10

Microsoft has released a
critical patch impacting
all Windows Server Operating System Versions with the DNS role installed. The
included affected operating systems are: 2003 – 2019.

This patch has a significant risk of being exploited, and if an attacker
successfully exploited the vulnerability, they could run arbitrary code in the
context of the Local System Account. As most organizations install the DNS
Server role on their Domain Controller, the attacker would gain full control of
a Domain Controller. Once the attacker has full control of the domain
controller, lateral movement to any Domain joined system is possible.
https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/
There are no known uses in the wild of this. It is highly recommended you patch
all windows DNS servers (internal and external) that you may own as soon as
possible.

WHAT YOU NEED TO DO

In order to secure your environment as soon as possible, you should complete
the following steps as soon as possible.
 

  1. IDENTIFY –  ALL WINDOWS DNS
    servers in your environment – both internal and external. – You can use
    PowerShell to help
  2. TEST – The applicable monthly
    servicing stack, and cumulative update for the server operating system.
  3. DEPLOY – The applicable patch to all DNS
    servers in your environment as soon as possible.

NIST Releases Draft SP 800-181 Revision 1 for Comment

The National
Initiative for Cybersecurity Education (NICE)
 has released Draft NIST Special Publication (SP)
800-181 Revision 1,
Workforce Framework for Cybersecurity (NICE Framework).
The NICE Framework is a fundamental reference for describing and sharing
information about cybersecurity work in the form of Task Statements and as Work
Roles that perform those tasks. In this revision, several updates have been
made, including:

  • an updated title to be more
    inclusive of the variety of workers who perform cybersecurity work, 
  • definition and normalization of
    key terms,
  • principles that facilitate
    agility, flexibility, interoperability, and modularity,
  • introduction of competencies,
  • and more!

The
public comment period is open through August 28, 2020.
See the publication
details
for a copy of the document and instructions for submitting
comments

Outlook Crashing on Launch

Active Investigation into Outlook Crashing on Launch

There is a new symptom of Outlook is crashing on launch starting 7/15.   A fix has been published but will take time to propagate to worldwide availability.   Outlook will automatically look for the fix on launch, so if this issue persists through multiple launches please use Outlook Web Access for an hour then try again.   
If this issue persists beyond four hours please contact Microsoft Support by whichever means works best for you.
  1. You may see an error such as:
    “Outlook couldn’t start last time. Safe mode could help you troubleshoot the problem, but some features might not be available in this mode.
    Do you want to start in Safe Mode?”
  2. In the event viewer you will see a crash event like:
    1. Faulting application name: OUTLOOK.EXE, version: 16.0.13102.20002, time stamp: 0x5efe7a9e
      Faulting module name: OUTLOOK.EXE, version: 16.0.13102.20002, time stamp: 0x5efe7a9e
      Exception code: 0xc0000005
      Fault offset: 0x00000000001a40fa
      Faulting process id: 0x3f60
      Faulting application start time: 0x01d65ac2602949dd
      Faulting application path: C:Program FilesMicrosoft OfficerootOffice16OUTLOOK.EXE
      Faulting module path: C:Program FilesMicrosoft OfficerootOffice16OUTLOOK.EXE
      Report Id: 81a20cc2-6c7f-4635-90ba-54319c3fce75
      Faulting package full name:
      Faulting package-relative application ID:
       Microsoft suggests users use web and mobile clients until the issue is resolved.
      Title: Users experiencing Outlook connection issues and crashes
      User Impact: Users may experience crashes or may be unable to access Exchange Online via Outlook.
      More info: Our analysis indicates that Outlook on the web and mobile clients are unaffected. Users may be able to leverage those protocols as an alternative means to access email and service features while we remediate this problem.
      Current status: Our initial review of the available data indicates that recently deployed updates are the likely source of the problem. We’re performing an analysis of all recent service updates to isolate the underlying cause of the problem and to determine the most expedient means to restore service.
      Scope of impact: This issue may potentially affect any of your users attempting to use Outlook.
       you could try 

      Open cmd, run:
      cd “Program FilesCommon Filesmicrosoft
      sharedClickToRun”
      then:
      officec2rclient.exe /update user
      updatetoversion=16.0.12827.20470