Ofttimes it has been difficult to explain the role of software protection in hardware-protected secure systems, but recently security researchers have helped us out by providing many examples of zero-day exploits where flaws that are baked into hardware or firmware lead to exploitable vulnerabilities in systems. In this article we are having a look at Spectre & Meltdown and explore how these attacks could have been avoided using application protection technology.
Some of you will remember the Target and Home Depot cyberattacks in 2013 & 2014, which resulted in $202 million (Sruthi Ramakrishnan, 2017) and $134.5 million USD (Roberts, 2017) of damages respectively. In this blog article, let’s examine these and other infamous hacks in detail to glean important lessons about system and application security.
Following on from previous posts (part 1, part 2) I wanted to drill down a bit more into the components from the container cluster node in the reference architecture as is shown on the image below. […]
Introduction While investigating new solutions I was spinning up POC’s and decided that instead of either making a new jumphost every time or adding manually the access to my existing jumphost I just wanted the […]
In part 1 of this series of blog posts, we talked about how the choice between NoSQL and SQL databases is bound to the core design of the application and I promised to get deeper into what this means. We started by looking into how support for a flexible schema is both advantageous and challenging. In this post, I will discuss CAP theorem and explain how it affects both the choice of the database technology and the application logic. Understanding CAP theorem and its implications is very important in designing a distributed system.
In my previous post I advocated reducing the security perimeter to the smallest possible size – because perimeter based security is often not enough, the slightest ‘hole’ in the perimeter allows attackers to get in. […]
At Irdeto we have been working with AWS for some time. Our standard deployments are on AWS and this has led to improved visibility on costs. Of course, once you have that visibility there is always […]
Hosting a Java application in Docker is relatively easy and described in many howtos and tutorials. But what they don’t tell us is how to run Java inside Docker in production… Let me explain.
I recall in early 2000’s having a debate with a security expert about firewalls, at the time they were advocating the firewall model was fundamentally broken! Their argument was if any traffic could get through, in any direction, for any purpose, bad guys could figure out how to use it to exploit the system. I disagreed, believing the ‘new’ filtering technology would be able to stop them, I was wrong.
When choosing the database technology for an application, the most important question is whether to stick with the good old SQL databases, or follow the trend and choose NoSQL. The answer to this question is not as easy as the names (SQL or not) suggest. There are lots of checklists out there trying to help you make the right choice, and they are very helpful for quickly shaping our minds around the topic. However, in my experience, this is more than a checklist topic, rather you need a deep understanding of both technologies. If you are from same era as I am, you have received education or gained experience with SQL databases, probably with none or little knowledge of NoSQL databases. For us, data manipulation and storage have always been tied to relational models, until we heard about the seemingly opposite word of NoSQL. It is just natural to first grasp the new concept in the same light as the old model with supposedly the biggest difference to be ‘not having strict schema’, which sounds just like what we needed. However, there is a lot more to it. We need to dive beyond the shape of stored data or the retrieval options such as ‘to JOIN or not’.