The end of life of EV certificates?

Public key certificates play an essential role in PKI-based security systems. In protocols such as HTTPS, a certificate can be used to build the trust relationship for the client browser. There are different types of certificates, each one providing a level of trust to the client. The simplest one is the Domain Validated (DV) certificate, which is issued if the CA ensures that the requester controls the domain name. The next type is called the Organization Validated (OV) certificate, which provides more trust since the CA verifies the business behind the requesting website and provides the company name in the certificate. The highest level of trust is provided by Extended Validation (EV) certificates, where the CA requires extra documents to verify the requesting business.
The benefit of EV certificates compared to OV and DV ones was the way web browsers treat them. That is, depending on the browser, the address bar became green and the company name was displayed before the URL. These visual signs were aimed to help the users recognize fraudulent websites.
However, the visual signs of EV certificates are no longer supported by major browser vendors as mentioned by Troy Hunt. It seems that the major benefit of EV over other types of certificates is disappeared.

Nmap as a vulnerability scanner

How do you discover vulnerabilities in your network? It is clear that some vulnerabilities (e.g., network design vulnerabilities) need more than a scanner to be identified. There are various commercial and free tools to scan your assets and determine if they are up-to-date and if they are properly configured. Nmap is one of those tools that can be used as a vulnerability scanner. The NSE (Nmap Scanning engine) provides various scripts to check operating systems, services and devices for a specific vulnerability. There are also scripts such as vulners which check the target against a number of vulnerabilities. According to the project page you can use it as follows:

nmap -sV --script vulners [--script-args mincvss=<arg_val>] <target>

Note that the script needs the software version to work correctly, hence the ''-sV'' switch is used.

OWASP API Security Top 10 Release Candidate

OWASP, the defacto reference for web applications security standards, has published information about Top 10 Release Candidate for API Security. From the official project page:
"By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.API Security focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of Application Programming Interfaces (APIs)."

The proposed domains are as follows:

A1: Broken Object Level Authorization
A2: Broken Authentication
A3: Excessive Data Exposure
A4: Lack of Resources & Rate Limiting
A5: Broken Function Level Authorization
A6: Mass Assignment
A7: Security Misconfiguration
A8: Injection
A9: Improper Assets Management
A10: Insufficient Logging & Monitoring

According to the project roadmap, the cheatsheet is expected to be published in 2019 Q4. These domains can be used to derive basic security requirements for API-based applications.

Open-source Network Intrusion Detection Systems

Network visibility is essential to security monitoring. You can not secure what you can not see or you are not aware of. In this sense, Network-based Intrusion Detection Systems (aka NIDS) help to identify and assess what is happening between network entities. Even by a simple signature-based IDS, you can receive useful information of what is happening behind your firewalls, for example, a vulnerable service which needs an update, or a compromised node that is generating malicious network traffic. Besides, NIDS is a valuable source of information for your SIEM and SOC. 

For a long time, Snort was the only option for those wish to try an open-source IDS. I've worked with Snort years ago, and also used it in conjunction with Linux Iptables to build a NIPS. I also have experienced the Suricata NIDS. It is a great open-source IDS, especially when it is used with ELK stack. SELKS provides such a platform, in which you have the Suricata engine and ELKS to store logs, manage Suricata rules and enjoy built-in dashboards as well as create custom ones. 

Now I want to try other open-source NIDS tools. A quick google search reveals these ones: 

https://wazuh.com

https://www.opnids.io 

https://www.zeek.org 

So it seems there are interesting options to try. 

 

Modules of PCI SSF

The requirements of PCI Software Security Framework are divided into two groups: Core requirements and Account data protection. The core requirements of secure software are applicable to all payment software, regardless of what the functions a]or underlying technologies are. Account data protection regards any application that stores, processes and/or transmits Sensitive Authentication Data (SAD) or Cardholder Data (CHD).
A direct consequence of the above definitions is that a PCI secure software may be allowed to store CHD where applicable according to the standards' requirements. This is the tricky point that is misunderstood by some organizations.

SELKS: Suricata IDS powered by the ELK

SELKS is a fantastic network-based intrusion detection system. It uses Suricata as the IDS engine, as well as the Elasticsearch/Logstash/Kibana (ELK) as the log management system. I've teste the 4th version, although today it's 5th version is stable. As I remember, installation of the VM distribution is straight, configuring the ELK subsystem is somehow tricky, while the other subsystems are easy to set up. You can enjoy pre-built dashboards, and also can build your own ones.

PCI SSF is more than a SDL

According to the PCI blog, ''Key security principles addressed in the Secure Software Standard include critical asset identification, secure default configuration, sensitive data protection, authentication and access control, attack detection, and vendor security guidance.'' That is, the SSF is more than the so-called Security Development Lifecycle (SDL). It includes all the standards and aspects that should be considered in a payment application regarding payment data security as well as how to validate and maintain the software.

PCI Software Security Framework

PA-DSS, which has been longly recognized as the defacto standard for payment applications data security, will be replaced by the recently published standard ''Software Security Framework'' by the end of 2022. PA-DSS validation requests submitted by vendors will be accepted till June 2021. In a recent FAQ published on PCI SSC blog, the relationship between the new security framework and the PA-DSS standard has been explained as: 

''The PCI Software Security Framework is separate and independent from PA-DSS. While the PCI Software Security Framework includes elements of PA-DSS, the Framework represents a new approach for securely designing and developing both existing and future payment software. PA-DSS was designed specifically for payment applications used in a PCI DSS environment. The PCI Software Security Standards extend beyond this to address overall software security resiliency. The PCI Software Security Framework is designed to support a broader array of payment software types, technologies, and development methodologies in use today and also support future technologies and use cases.''

In future posts, I will take a glance at SSF.