Dec 19, 2020

Incident Mgmt Vs Vulnerability Mgmt

Everyone agrees that Incident Management is different than Vulnerability Management. But yet still people mix them up when things happen.

Recently, SolarWinds supply chain attack has becomes the hottest topic in the month of December 2020 for Cybersecurity world. With the SUNBURST or SuperNova backdoors found, it is obviously becomes an incident (rather than a vulnerability) if your company is using the affected products. With the investigation is still ongoing, more affected products might be included in the list.

But, why people try to manage the SolarWinds case with vulnerability management? Is it because everyone is more familiar with vulnerability remediation process.

Yes, both incident management and vulnerability management has the remediation process. However it is performed by different teams. The remediation process for an incident is performed by Cybersecurity team, while the remediation process for a vulnerability is performed by IT team.

I guess people just thought that the all remediation process are the same.

Why people mix them up so easy?

I think it is due to sophisticated Cybersecurity team structure. And there is monthly remediation reminder that continuously reminding us on the remediation process. People just like to engage with what they are familiar with.

If your company is using a vulnerability management process to handle the SolarWinds attack or incident, then you should start think about simplifying your Cybersecurity teams. 

Dec 5, 2020

Retirement of Enhanced Security Admin Environment ESAE

Today, I just found that Microsoft has stopped their ESAE strategic architecture. Microsoft has recommended new strategy to complements any existing ESAE implementation. 

The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is an approach to provide a secure environment for Windows Server Active Directory (AD) administrators.

In early 2018, where I first learned about ESAE. After a deep dive evaluation, my conclusion is, it is too costly to implement such a solution, in term of operating cost, for most of the company (even it is a secure strategy). This is simply because the strategies have never consider the essential security concept. #EssentialSecurity 

And after 3 years, Microsoft has admitted that the ESAE architectural pattern is only valid or applicable in a limited set of scenarios. Any organization who implement ESAE architecture, must accept the increased technical complexity and operational costs of the solution. 

The ESAE retirement post can be found at https://docs.microsoft.com/en-us/security/compass/esae-retirement


Dec 1, 2020

GUI bug in KennaSecurity

There is a minor bug found at the Kenna's user interface that I encounter today.

To simulate the bug, from the Dashboard, look for any Kenna meter that has zero asset count (or you can create one), click on it to explore the asset/vuln list. And you will found that most of the filters are missing at the Explore page, such as:

  • (Asset Filters) Active/inactive
  • (Asset Filters) Tag
  • (Asset Filters) Sort by (everything)
  • (Vulnerability Filters) Status
  • (Vulnerability Filters) Classification
  • (Vulnerability Filters) Connector names .....
  • (Vulnerability Filters) custom fields.....

 😞😞

Nov 28, 2020

New Tools for your Threat Hunting Toolbox

Just finished watching the Youtube video on Mark's presentation. He has introduced 2 of the tools that he created for threat hunting. 


First, he introduces APIify that make anything query-able by SEIM, which used to automate the first few steps in every investigation.Second, is the Domain Stats 2.0 which helps to cache those whois requests for SIEM.

Links:

  • https://github.com/MarkBaggett/apiify



Nov 18, 2020

[Vuln] More About Zerologon Vulnerability (cve-2020-1472)

The cve-2020-1472 vulnerability has been disclosed since Aug. This is an elevation of privilege vulnerability that exists when a vulnerable Netlogon secure channel connection to a domain controller, using the Netlogon Remote Protocol.

This vulnerability is more to be known as Zerologon, and received a CVSS score of 10.0. Here're the summary of the vulnerability:

  • Proof of concept available [ yes ]
  • Unauthenticated attack [ yes ]
  • Admin privileged access [ yes ]
  • Easy to weaponize [ yes ]
  • Remote attack [ same LAN only YES ] **

Al least last point seems like a good news where a vulnerable client or DC exposed to the internet is not exploitable by itself. (whew)

There are 2 things I would like to emphasis in this post. 

First, the patch released in August isn't a full fix solution. The patch only helps to protect the vulnerable servers (domain controllers) from exploit/malware attack. This is like deploying an antivirus solution that block the WannaCry malware without patching the root problem. 

The root of the problem is at the RPC with Netlogon protocol (MS-NRPC). And Microsoft will release second patch slated for Q1 in 2021 to address the bug.

The NetLogon component is an important functional component to perform authentication on the intra-domain network. It is important to be used for replicating the database backup, and maintaining domain members and domains relationship with domain DC (or cross-domain DC). The worst case for this attack is, the DC can be takenover by unauthenticated attacker.

Second, this vulnerability is targeting mainly on domain controllers (DC), including Samba server. However, the default installation running Samba (as a file server) are not directly impacted.

To Samba, this vulnerability is more of a mis-configuration than bug. Samba has been insisting on a secure netlogon channel since version 4.8 (Mar 2018). This is sufficient fix against the zerologon attack. [Unless they have the smb.conf lines 'server schannel = no' or 'server schannel = auto', those Samba server is not vulnerable]

Samba versions 4.7 and below are impacted by the vulnerability unless they have ‘server schannel = yes’ in the smb.conf. “The ‘server schannel = yes’ smb.conf line is equivalent to ‘FullSecureChannelProtection=1’ registry key in Microsoft OS, the introduction of which we understand forms the core of Microsoft’s fix. ”

Link: