How to Simplify Cybersecurity?

We already knew that complexity is the enemy for Cybersecurity. As the threat environment has gotten more sophisticated, it is very likely those (sophisticated) organization responded to new threat by adding new tools to their security stack.

I always believe that "less is more" is also applicable in Cybersecurity world. With all these new challenging threats nowadays, we as the Cybersecurity leaders should take control of the tools/environment, and reducing complexity by leveraging fewer tools, so it can be more efficient and effective at their daily uses.

But how can we do it? 

Based on my 13 years experience, it is possible with the correct approach and people. Here are my recommendations:

1. Automation 
• Try to automate any process, especially those repetitious process like vulnerability remediation, whenever possible.
  
2. Integration (but not consolidation)
•  Don't consolidate the tools as "defense in depth" still applicable in Cybersecurity.
• Use JSON/XML to integrate the tools for measuring any metrics.
  
3. Orchestration
•  Invest in centralized logging SIEM helps orchestrate and streamline the workflow.
  
4. Using cloud for the cloud
• Invest in modern cloud tools rather than using the traditional tool to manage the cloud.
• Then integrate both the new and old tools.
5. Public Relationship Education
• Invest a strong team that can help to communicate security updates and building the trusts with other organizations.
• The team can also provide education for others and set as single channel for communication.
  

With all the modern infrastructure, like mobile apps, IoT, hybrid clouds and DevOps being added to our operating environment, we still need to ensure Cybersecurity can grow faster and work smarter. The answer to this is Simplify Cybersecurity.  And the key to Simplify Cybersecurity is to take a "less is more" approach. 

Keep in mind that simplicity is the ultimate sophistication.

Who should be driving Simplify Cybersecurity ?

Following from the previous Simplify Cybersecurity posts, I'll should you in more details what is Simplify Cybersecurity.

Imagine, your company is entering the digital transformation for IT organization, and you need to transform the Cybersecurity organization too.

By following Simplify Cybersecurity principle, it is very easy to "transform" the Cybersecurity organization.

Even by entering the cloud world, the Cybersecurity core functions haven't changed much. It is still required to Identify, Protect, Detect, Respond, and Recover. The only thing question is, who should be leading the work.

Depends on which stage or which generation of Cybersecurity org is, all you need to do is expand the size/budget of the driving team. For example, nowadays, many company are entering cloud world. And by based on the generation in Simplify Security Stage article, it should be the IAM team that drive the Cybersecurity transformation, and help the whole organization get ready for cloud-based security. 

Many company makes a mistake by forming new team, like cloud security team, to get prepare for company to enter the cloud world. And this is where the Cybersecurity start to get sophisticated. IMO, the CISO may simply have no idea what should be the driving factor in different stage/generation.

CVE-2018-1002105 PoC

In all Kubernetes versions prior to v1.10.11, v1.11.5, and v1.12.3, incorrect handling of error responses to proxied upgrade requests in the kube-apiserver allowed specially crafted requests to establish a connection through the Kubernetes API server to backend servers, then send arbitrary requests over the same connection directly to the backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection.

There are 2 POC been released for CVE-2018-1002105.

Authenticated PoC

Proof-of-Concept exploit for CVE-2018-1002105. The current exploit requires create and get privileges on pods and pods/exec. Support has been added for portforward and attach, which require similar permissions.

The current PoC dumps the secrets from the default etcd-kubernetes pod. 

Unauthenticated PoC

The unauthenticated PoC allows privilege escalation within the context of the exposed API. Depending on the functionalities of the API it might be possible to get code execution on pods. This demo currently exploits the bug to gain cluster-admin rights on the servicecatalog.k8s.io API. This exploit should also work for metrics.k8s.io or any API exposed through the aggregated layer.

Links:

• https://github.com/evict/poc_CVE-2018-1002105
  

What is Simplify Cybersecurity?

Once we know why should we simplify Cybersecurity, we need to know what is Simplify Cybersecurity.

IMO, Cybersecurity cannot (and should not) operate like an IT team. It is very likely you will end up with a very complicated Cybersecurity organization if you try to do so. In another words, we shouldn't have engineering team or operation team, just like how normally IT organization does.

Then, what should a Simplify Cybersecurity organization look like?

Cybersecurity, is all about risk management. And based on NIST Cybersecurity Framework, there should be 5 core functions which include: Identify, Protect, Detect, Respond, and Recover. 

A simplified Cybersecurity organization can follow the NIST framework here. Here's an example:

1. Identify
• Governance, Risk and Compliance team
• Project Management and Consultation team
  
2. Protect
• Network Security team
• Security Architecture and Strategy team
• Identity, Access and Management team
  
3. Detect
• Security Assurance team
  
• Threat and Vulnerability Management team
4. Respond
• Incident Management team
  
5. Recover
• Forensic and Investigation team
• Disaster and Recovery Planning team
  

Note that, the 5 core functions are merely the virtual triage, and not necessary a real team. Next, we will examine in more details about what Simplify Cybersecurity is.

Static Key Cipher Vs Perfect Forward Secrecy

In cryptography, symmetric encryption, there are 2 ways to handle the session key. One is static key cipher, and another is Perfect Forward Secrecy (or simply Forward Secrecy).

Forward secrecy, is a feature key management that ensures session key will not be compromised if the long-term secrets (private signing key) used in the session key exchange are compromised. This means by compromise a single session key, it will not affect any data other than that exchanged in the specific session protected by the key.

Thus, FS can protects past sessions against future compromises of keys. But static key cipher is the other way. By using static key cipher, compromise of single session key (in the future) will lead to compromise of all the past encrypted session.

During the cipher suite negotiation, the client sends a handshake message with a list of cipher suites it will accept.  The server chooses from the list and sends a handshake message back indicating which cipher suite it will accept.  Although the client may order the list with the strongest cipher suites listed first, the server may choose any of the cipher suites proposed by the client.  (The client may even send those cipher suite with weakness to server) Therefore there is no guarantee that the negotiation will settle on the strongest suite in common.  If no cipher suites are in common the connection is aborted. 

Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. 

Note that by restricting to TLS 1.2 cipher suite doesn't guarantee forward secrecy is always been used. For example, below are a list of TLS 1.2 approved ciphers, and those highlighted are still using static key cipher.

•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
•     Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
•     Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
•     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
•     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
•     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
•     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
•     Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Note that FS is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations. But, FS cannot defend against a successful cryptanalysis of the underlying ciphers being used. This is because, FS only protects keys (not the ciphers). If a cryptanalysis found a way to decrypt an encrypted message without the key, then FS cannot help here.