DEV Community: Hored Otniel

Introduction to PCI DSS and its contribution to FinTech companies

Hored Otniel — Wed, 08 Mar 2023 10:42:42 +0000

The emergence of multiple online payment solutions has completely transformed the online payment landscape. This revolution has not only led to the exponential growth of e-commerce but also completely revolutionized the way we conduct financial transactions. Today, businesses across industries have embraced the digital world, capitalizing on the benefits offered by online transactions. Nevertheless, it is known that many security risks exist online. Indeed, the financial system is one of the most targeted areas for cyber attacks. As a result, cybersecurity has become a major concern for the entire FinTech ecosystem, impacting every aspect of the industry.

The PCI DSS is one of the main standards that protect users' credit card data. In this article, we will discuss the PCI DSS, its requirements, how it works and how it can help online payment institutions.

What is PCI DSS ?

PCI DSS stands for Payment Card Industry Data Security Standard. It is an information security standard used to handle credit cards from major card brands. The standard is administered by the Payment Card Industry Security Standards Council and it is mandatory for companies that process, store, or transmit cardholder data (CHD) or secure authentication data (SAD) to comply with PCI DSS requirements. The standard was created to better control cardholder data and reduce credit card fraud. The Payment Card Industry Data Security Standard (PCI DSS) defines the minimum technical and operational requirements for data security. The current version of PCI DSS 4.0 was published the March 31, 2022. You can download it here.

Who created PCI DSS?

The PCI DSS was created jointly in 2004 by four major credit-card companies: Visa, MasterCard, Discover and American Express. But when it comes to the history of the Standard we need to mention some details. Indeed Visa was the first of the major card companies to attempt to establish a set of security standards for businesses that accepted online payments. Visa announced the Cardholder Information Security Program (CISP) in 1999 and implemented it in 2001. Mastercard, American Express, and Discover will then offer their own security programs.

Not surprisingly, a problem soon arose. Merchants who used to accept multiple credit card brands are now faced with multiple security compliance programs. This has only led to an increase in payment fraud. To find a solution, American Express, Discover Financial Services, JCB International, Mastercard, and Visa have come together to form the Payment Card Industry (PCI) which will introduce PCI DSS 1.0 in December 2004.

PCI DSS Requirements

PCI DSS 4.0 is designed to further secure cardholder data by helping businesses adopt security measures and access controls. Each requirement of the standard is linked to an objective. In the following, the requirements are organized as sub-elements of the objective that is being addressed

Goal	Requirement
Build and Maintain a Secure Network and Systems	Requirement 1: Install and Maintain Network Security Controls Requirement 2: Apply Secure Configurations to All System Components
Protect Account Data	Requirement 3: Protect Stored Account Data Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Maintain a Vulnerability Management Program	Requirement 5: Protect All Systems and Networks from Malicious Software Requirement 6: Develop and Maintain Secure Systems and Software
Implement Strong Access Control Measures	Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know Requirement 8: Identify Users and Authenticate Access to System Components Requirement 9: Restrict Physical Access to Cardholder Data
Regularly Monitor and Test Networks	Requirement 10: Log and Monitor All Access to System Components and Cardholder Data Requirement 11: Test Security of Systems and Networks Regularly
Maintain an Information Security Policy	Requirement 12: Support Information Security with Organizational Policies and Programs

With regard to these requirements, the standard associates test procedures with the requirements. Thus, in terms of security, each requirement involves defined approaches which are associated with test procedures. The test procedure is used to verify compliance.

What are the PCI compliance levels?

Although the PCI DSS is a unified standard that takes into account the rules of all the major players in the PCI Security Standards Council (PCI SSC), its criteria can have subtleties that depend on the number of transactions made by the payment solution and the number of users. Thus the PCI SSC has established a list of compliance levels that explains the requirements to all responsible parties.

Level 1: The first level sets requirements for companies that process more than 6 million Visa or Mastercard transactions per year, or more than 2.5 million American Express transactions, or those that have suffered a data breach.
Level 2: This level applies to companies that process between 1 and 6 million transactions per year.
Level 3: This level applies to companies that process between 20,000 and 1 million online transactions per year.
Level 4 : It’s the lowest compliance level for companies that process less than 20,000 transactions per year.

How PCI DSS compliance works

As regards compliance, how does the PCI DSS certification process work? The PCI DSS certification process involves an audit of the company. The first step is an assessment (details vary depending on your level), a quarterly network analysis, and the Attestation of Compliance.

For first-level companies, the process involves :

The completion of an Annual Report on Compliance(ROC) by a Qualified Security Assessor (QSA). The assessment takes place within the organization for :

Validate the scope of the assessment;
Review your documentation and technical information;
Determine whether the PCI DSS’s requirements are being met;
Provide support and guidance during the compliance process; and
Evaluate compensating controls.

Quarterly network analysis is carried out by an approved scanning vendor (ASV). The Attestation of Compliance (AOC) for assessment must be produced.

For level 2-4 companies, there is a self-assessment questionnaire (SAQ). There are 9 different questionnaires. Each of the 9 self-assessment questionnaires has its own AOC form. Level 2 organisations must also complete an ROC.

Why FinTech Companies Should Prioritize PCI DSS Compliance

As explained in the chapters above, the PCI DSS is aimed at the security of cardholder data. Indeed, it is a standard that allows a company operating in online payment services to comply with rules that will ensure the security of the information it holds.

The PCI DSS standard can really be the foundation for the security of a fintech company's IT infrastructure. Indeed, the requirements of this standard lead companies to implement the necessary methods to ensure a certain level of security against cyber attacks. For example, by following this standard, organizations are required to put in place, among other things :

securing key physical access areas
monitoring network access
conducting regular penetration tests
limiting access to data
deploying secure hardware and software

These methods not only guarantee the security of data but also foster a relationship of trust between merchants and their customers.

As a standard established by the Payment Card Industry Security Standards Council ("PCI SSC"), PCI DSS can provide businesses with a significant boost in credibility when it comes to processing credit card data. By implementing the rigorous security measures required by the standard, companies can demonstrate their commitment to protecting their customers' sensitive data. This, in turn, can help build trust and confidence in their services among end-users. Ultimately, by obtaining PCI DSS certification, businesses can differentiate themselves in a crowded marketplace and position themselves for long-term success.

However, it is important to clarify that PCI DSS compliance is a complicated and costly process for businesses.

Log centralization and security alert with ELK (part 1)

Hored Otniel — Sat, 20 Aug 2022 10:45:00 +0000

As a SysAdmin, DevOps, or cybersecurity analyst, the moment will inevitably come in your work when you will need to consult the logs to investigate an incident or a bug.

Imagine a scenario where one of your collaborators often allows himself to connect in ssh as 'root' on the servers, or a scenario in which your main database replication server is down, wouldn't it be interesting to have a place where you have all these information without having to log in on each server?

Log aggregation

In the previous scenarios, the best way to quickly have all these information is by log aggregation. So what is log aggregation?

Log aggregation is the process of collecting and standardizing log events from various sources across your IT infrastructure for faster log analysis. Log aggregation is one of the early stages in the log management process. With log aggregation, you have the assurance of having centralized the logs and of having a tool for analyzing the logs.
Using log aggregation gives you a lot of advantages. Indeed, you can:

Perform real-time monitoring
Troubleshoot production incidents
Centralize logs in the same location
Collaborate with others on log analysis
Enhanced Security in your infrastructure

Elasticsearch-Logstash-Kibana

ELK is a log analysis suite composed of 3 open source tools, developed by the company Elastic: Elasticsearch, Logstash and Kibana.

ElasticSearch is a search and analysis engine that uses the JSON format. Its goal is to efficiently extract data from structured or unstructured data sources in real-time. Elasticsearch uses Lucene to provide the most powerful full-text search capabilities available in any open-source product.

Logstash is a tool for entering, processing, and outputting log data. Its function is to analyze, filter, and cut the logs to transform them into formatted documents for Elasticsearch.

Kibana is an interactive and configurable dashboard that allows you to visualize the data stored in ElasticSearch. Kibana provides insight into trends and patterns in all forms of diagrams and curves. This dashboard can be shared and combined with data visualizations for quick and smart communication.

For the collection of data, Elastic has planned the beats which are agents that you install on your machines to monitor.

With this stack, you, therefore, have the possibility of setting up a centralized system (SIEM) that offers total visibility on the activity of your infrastructure and which thus allows you to react to threats in real-time.

Image source

In the rest of this article, we will therefore make a demo where we will set up the suite for elk to collect logs from a machine and visualize the dashboards on kibana.

Demo

Disclaimer: In this article, we will not cover logstash. Logstash is not essential for what we want to do in this series.

To realize our work here, we will use a server to install elk. The information-gathering agents (Filebeat, metricbeat...) will be installed on a host.

The server used to install elk is a GCP server with the following specifications:

25GB of disk space
4GB of memory

Although these are fairly minimalist features, they should suffice for this item.

Prerequisites

Make sure you have java installed and that ports 9200(elasticsearch) and 5601(kibana) are open on your server.

Elasticsearch

We will start by importing the Elasticsearch public GPG key.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

After that, you have to get OK

Next, we add the Elastic source list to the sources.list.d directory :

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee –a /etc/apt/sources.list.d/elastic-7.x.list

Install and configure elasticsearch

After that, you have to update your system and install elasticsearch

sudo apt-get update

sudo apt-get install elasticsearch

To configure elasticsearch, we will modify the file /etc/elasticsearch/elasticsearch.yml

sudo nano /etc/elasticsearch/elasticsearch.yml

The most important things to change:

network.host
http.port
discovery.type

After that, we start the service:

sudo systemctl start elasticsearch

You also need to allow Elasticsearch to start every time the server starts.

sudo systemctl enable elasticsearch

After that, we check if everything works well with an HTTP request. In my case, since I used my IP address, I use it for the request:

curl -X GET "your_ip:9200"

If you used localhost, it comes out to :

curl -X GET "localhost:9200"

Kibana

Install and configure kibana

To install kibana :

sudo apt install kibana

sudo systemctl enable kibana

sudo systemctl start kibana

After that, we configure kibana by modifying the file /etc/kibana/kibana.yml. The most important elements that we modify here :

server.port: 5601

server.host: "0.0.0.0"

elasticsearch.hosts: ["http://localhost:9200"]

For elasticsearch.hosts replace localhost if you have configured elasticsearch on another IP address.

Let's restart the service

systemctl restart kibana

You should normally have access to the kibana dashboard with http://localhost:5601 ou http://your-ip:5601 :

As you may have noticed when logging into kibana, no authentication is required. While this doesn't particularly bother our work here, in a real environment, we can't let the dashboard be accessible so easily. So we will add authentication to our dashboard. To do this, elastic has prepared some tools that we can use.

First, we need to stop the two services

systemctl stop elasticsearch kibana

In the file /etc/elasticsearch/elasticsearch.yml, let's add :

xpack.security.enabled: true

To communicate with our cluster, we need to configure a username for the embedded users. For this we have a program elasticsearch in the folder /usr/share/elasticsearch/. So start by stopping the elasticsearch service and running the following command from the folder :

./bin/elasticsearch

Then in another terminal :

./bin/elasticsearch-setup-passwords auto

You must answer with "y" here for this step

After that, you will get the passwords for the different users as shown here :

Then we have to go back to the kibana configuration file to authenticate the user kibana_system. Otherwise, kibana and elasticsearch will not be able to communicate.

The following information must be added to the configuration by filling in the credentials obtained earlier. The user to indicate here is kibana_system

elasticsearch.username: "kibana_system"
elasticsearch.password: "your_password_for_kibana_system"

You have to restart elasticsearch and kibana and voila! 😎

As you can see kibana requires authentication. You have to connect with the credential of the user elastic

Beats

If you browse a bit on kibana you will notice that we don't have any dashboard currently.

This is quite normal since we have not created any dashboard and especially we have no data in elasticsearch for that.

To solve this problem, we will use metricbeat.

Metricbeat

Elastic define Metricbeat as a lightweight shipper that you can install on your servers to periodically collect metrics from the operating system and from services running on the server. Metricbeat takes the metrics and statistics that it collects and ships them to the output that you specify, such as Elasticsearch or Logstash.

The installation of Metricbeat is quite simple. You have to install it on the host you want to monitor and then configure it to send information to elasticsearch. We use version 7.17.5 of elasticsearch in this tutorial. So we have to install the same version of metricbeat.

So we start by downloading the deb package here

Then we proceed to the installation with :

sudo dpkg -i metricbeat-7.17.5-amd64.deb

After that, you have to configure the file /etc/metricbeat/metricbeat.yml

In the basic configuration that we exploit here, we change the following elements:

setup.kibana:

  # Kibana Host
  host: "your_ip:5601"


output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["localhost:9200"]
  #username: "elastic"
  #password: "changeme"

Take care to change the information according to your infrastructure. For the username and password, these are the credentials of the user elastic.

What is interesting with beats is that there are dashboards that are pre-loaded, which allows us to have a basic global view of the data transferred by the agent. You will be able to create your dashboards if you wish later on.

To initialize metricbeat and load the dashboards, use the following command:

sudo metricbeat setup -e

Normally this command will take some time to finalize the loading of the data and dashboards.

After that, you have to start the service.

sudo service metricbeat start

Then go to kibana to see the change

You can see that we now have a list of dashboards proposed by metricbeat. We are going to browse some dashboards concerning us to see the feedback. (It should be noted that some dashboards may be empty if your server to monitor does not have the metrics that concern this dashboard)

Let's take a look at [Metricbeat System] Host overview ECS dashboard

As the name of the dashboard indicates, we have an overview of the host. There is more information :

Let's take a look at another dashboard : [Metricbeat System] Containers overview ECS

As you can see, there is much less information than in the previous dashboard. This is due to the very few containers running on the host. The list of dashboards offered by metricbeat is quite large. You can also create your own dashboard.

Filebeat

The installation of filebeat is done following the same process as for metricbeat. Download the deb package here

You can also renew the basic configuration, taking care to change the modified information for metricbeat.

Here we can also indicate the folders where filebeat can fetch the logs.

- type: filestream
  # Unique ID among all inputs, an ID is required.
  id: my-filestream-id
  # Change to true to enable this input configuration.
  enabled: true
  paths:
    - /var/log/*.log
    #- c:\programdata\elasticsearch\logs\*

After that, we perform the setup and start the service.

sudo filebeat setup -e

sudo service filebeat start

Note that Metricbeat and Filebeat have modules that can be activated to get more information. Indeed if you have tools such as apache, Nginx, docker... you can activate the modules related to these tools to have data on the corresponding dashboard. You can consult the list of dashboards in the folder: /etc/filebeat/modules.d

To enable MySQL module for example :

sudo metricbeat modules enable mysql

sudo  metricbeat modules enable apache

You will need to re-setup and restart filebeat

We can see that you now have dashboards for filebeat.

Take the time to explore the dashboards. The basic dashboard that you will have with enough information will be that of Syslog.

You have to enable the service first with

sudo metricbeat modules enable system

Summary

In this tutorial we have covered the following points:

Installation and configuration of elasticsearch
Installation and configuration of kibana
Activation of authentication on kibana
Installation and configuration of metricbeat and filebeat
Exploration of some dashboards

What next?

So in this first tutorial, we have covered the interesting points concerning the implementation of the ELK stack but there is still a lot to discover. In the next part of the series, we are going to focus on setting up security alerts with a very great tool (Elastalert). It will also be an opportunity to come back to the possibilities that ELK offers us.

Log centralization and security alert with ELK (Part 2)

Hored Otniel — Sun, 24 Jul 2022 08:30:00 +0000

Assume that your information system has an enormous cloud infrastructure with lots of servers. As a cybersecurity engineer, it is your duty to put in place a set of processes to detect suspicious activities on the server, isn't it ?

If you know exactly what you're looking for, it's pretty easy to straightly head to the logs, inspect them and pull those things out. But in this specific case where you have loads of logs on different files, you obviously need a log management system and most importantly a tool to keep you alert to the slightest incident on your servers. This is where ELK and Elastalert2 come in

ELK Stack

In the first part of this series, we worked on deploying an ELK cluster and how to install beats on servers for monitoring. You should check this part if you haven't already because it is important to understand what will be going on in this second part.

Elastalert

ElastAlert is a simple framework for alerting on anomalies, spikes, or other patterns of interest from data in Elasticsearch. This tool allows you to write your rules for the alerts you want.

ElastAlert queries Elasticsearch and provides an alerting mechanism with multiple output types, such as Slack, Email, JIRA, OpsGenie, among others.

We are going to exploit here elastalert2 because the initial project is no longer maintained.

We will use our cluster previously set up in the first part.

Installation

Note that there are various methods to deploy elastalert. You can use a docker container but I preferred to use the python package option.

git clone https://github.com/jertel/elastalert2.git

Install the module:

pip install "setuptools>=11.3"
python setup.py install

This being done, you know that elasticsearch works with an index and it is important to create the index where Elastalert will store its data. For this purpose, the tool has prepared everything necessary.

elastalert-create-index

You will need to provide some informations such as the host, the port, the username to connect, the password or other optional information.

Great !! You just installed a very powerful tool for your security alerts. But keep in mind that in this article, we will address just a few basic rules.

Before going any further, you must choose and configure the means by which you wish to receive emails. Here I chose to use Slack.

Configuring Slack

You need to create the webhook on your slack channel.

For this we can follow this documentation: https://slack.com/help/articles/115005265063-Incoming-webhooks-for-Slack

We will first need to create an app in slack

Then add incoming webhooks as feature. You can connect it to the workspace you want to use. After that you need to copy the url you will use.

Once that is done, we can move on by writing our first rule.

First rule

So to test this tool we will use the rule examples/rules/example_frequency.yaml as a template.
Befor going on let's talk about the basics options you need to understand.
As it explained in the doc :

es_host and es_port should point to the Elasticsearch cluster we want to query.
name attribute must be unique. ElastAlert 2 will not start if two rules share the same name.
type: Each rule has a different type which may take different parameters. The frequency type means “Alert when more than num_events occur within timeframe.”
num_events: This parameter is specific to frequency type and is the threshold for when an alert is triggered.
timeframe is the time period in which num_events must occur.
filter is a list of Elasticsearch filters that are used to filter results. Here we have a single term filter for documents with some_field matching some_value
alert is a list of alerts to run on each match.

That is the most basic information you need to understand for this first rule.

What we will do is to make an alert about all command that has been executed as "root".

To do this let's check some informations on our dashboard.

Remember that in the first part we deployed filebeat to collect information such as system logs. To write our rule, watch this dashboard :

So we can see that in the last 15 minutes there has been a command executed as sudo.

This first alert will therefore consist of sending a message in our slack app as soon as the is executed. To do this, if you have understood the explanations of the options correctly, we are going to put:

type: frequency

index: filebeat-*

num_events: 1

timeframe:
  minutes: 1

filter:
- query:
    query_string:
      query: "system.auth.sudo.command: *"

Now we read in indexes prefixed with filebeat and as soon as the event occurs at least once in a minute. For the event in question, we use the fields that filebeat proposes to do the search. On the dashboard previously illustrated you certainly noticed the system.auth.sudo.command field, so it was relatively simple to write this filter.

Then the other very important part is the alerts

realert:
  minutes: 1

query_key:
  - host.ip

include:
  - host.hostname
  - user.name
  - host.ip

include_match_in_root: true

alert_subject: "sudo command on <{}>"
alert_subject_args:
  - host.hostname

alert_text: |-
  A command was executed as root on {}.
  Informations:
  User: {}
  IP: {}
alert_text_args:
  - host.hostname
  - user.name
  - host.ip

Remember the importance of realert here. The time defined will be the frequency of sending alerts. The other options use fields present in filebeat indexes for the alert.

The other part is the configuration of the alert tool in this case slack in our case.

alert:
  - slack:
      slack_webhook_url: "your_url"
      slack_username_override: "your_username"

You will also need to configure the config.yaml file in the example subdirectory. Once done, we'll test our rule:

elastalert-test-rule --config examples/config.yaml examples/rules/example_frequency.yaml --alert

And voilà!

As you can see, we received a message at the channel level. I hid sensitive information but you may notice the title and content as formatted in our alert.

Automating

As you may have noticed, we just tested our rule with the elastalert-test-rule command. But as you can guess, to secure a real information system, alerts must reach you in real time without you needing to enter a command each time.

So to automate the alert process, we'll go back to our config.yaml file.

The method I use is quite simple. In this file you have the possibility to indicate the folder where Elastalert will look for the rules with the option rules_folder. You also have the possibility to indicate other options which will be applied by default to all the rules. For example, es_host; es_port; es_username or es_username are fixed values.

Once this file is prepared and your rules are well written, all you have to do is write a cron job that will keep elastalert up to send you the alerts at your convenience.

5 4 5 10 5 /usr/local/bin/elastalert --config /opt/elastalert/config/config.yaml --verbose

I chose the periodicity of the job very randomly but you got the idea 😎️. So your alerts will reach you all the time.

Use case

Here we have covered the sudo commands but you have a non-exhaustive list of rules that you can set up using the appropriate beat indexes (filebeat, metricbeat...).

Disk space alert
ssh connections alert
Alert on uptime (heartbeat)
...

Elastalert is a very rich tool in terms of possibilities. Be imaginative and have fun with it.