Log in
Data security in the BHP Panic system: the NIST standard
As CLOUDPANIC, our most important mission is to deliver secure, high-performance applications. We specialise in building high-traffic solutions that, given the nature of the business, are particularly exposed to attack attempts. Our systems have processed transactions worth over €100 million.
Architecture based on the NIST standard
When we designed the BHP Panic security architecture, we wanted something more than a requirements checklist. NIST gave us a coherent way of thinking: what to protect, how to detect attack attempts and what to do when something goes wrong. We built security into every stage: from the first commit to deployment to production.
What is the NIST standard?
NIST(National Institute of Standards and Technology) is an American standards institute. ItsCybersecurity Frameworkstands out because instead of a list of requirements it provides a way of thinking: Identify, Protect, Detect, Respond and Recover.
Before we chose NIST we also considered other frameworks, including ISO 27001. We chose NIST because it fits cloud environments better and does not assume that the whole infrastructure is uniform.
Before we chose NIST we also considered other frameworks, including ISO 27001. We chose NIST because it fits cloud environments better and does not assume that the whole infrastructure is uniform.
Application layer protection
WAF and next-generation firewall
Every request to the application passes through a Web Application Firewall before it reaches any of our services. The WAF blocks scanners, SQL injection attempts and other typical attacks automatically, without our intervention. We update the rules regularly because threats evolve faster than a quarterly update. Besides the WAF, we have a next-generation firewall with an IDS/IPS module between the application zones. On several occasions it caught suspicious traffic before we had noticed it in the logs ourselves.
Secure container architecture
The entire BHP Panic system runs in containers. We build base images on minimalist Linux distributions: a few megabytes instead of several hundred, with no unnecessary system tools. Each container gets only the permissions it actually needs, with no shell access and no ability to change its own configuration while running. If an attacker gets into one container, they cannot jump from there to the rest of the system.
What is containerisation?
Containerisation is a way of running applications in specially “packaged” environments called containers. You can imagine a container as a box that holds everything a program needs to run: files, libraries, configurations. As a result the application always behaves the same, regardless of the computer, server or cloud it runs on. It is a bit like sending someone a meal in a box that contains not only the food itself but also exactly the plates and cutlery needed, so you know it can be eaten anywhere.
The second important feature of containerisation is isolation. Each container runs separately, without mixing with other applications. If one application stops working properly, it does not affect the rest of the system. In the traditional approach programs shared many common system components, so problems or updates in one could disrupt the others. Containers solve this, providing greater security, stability and ease of managing the whole environment.
The second important feature of containerisation is isolation. Each container runs separately, without mixing with other applications. If one application stops working properly, it does not affect the rest of the system. In the traditional approach programs shared many common system components, so problems or updates in one could disrupt the others. Containers solve this, providing greater security, stability and ease of managing the whole environment.
DevSecOps and penetration testing
Continuous security control
Every pull request goes through SAST analysis before it reaches code review. The scanner looks for vulnerabilities in the code: hardcoded secrets, unsafe file operations, basic logic flaws. We check dependencies separately with an SCA tool, because third-party libraries are a separate risk category and it is easy to forget.
Once a year we commission an external pentest. The latest report brought a few medium-category findings, no critical ones. We deployed the fixes within two weeks. We would rather know what we have to fix than live with a false sense of security.
The whole environment is monitored. Logs from every service go to a central system that alerts us when something deviates from the norm. We encrypt data both at rest and in transit. It is not an option, it is a condition.
Once a year we commission an external pentest. The latest report brought a few medium-category findings, no critical ones. We deployed the fixes within two weeks. We would rather know what we have to fix than live with a false sense of security.
The whole environment is monitored. Logs from every service go to a central system that alerts us when something deviates from the norm. We encrypt data both at rest and in transit. It is not an option, it is a condition.
