 Good morning everybody! We have still some seats available up front for those of you still entering. My name is Thijs Abos. I'm a father of a two-year-old and kind of concerned what will happen when he goes online, so I hope to make this world a bit safer before that point. In professional life, I'm an IT architect in ING, working at ING since 2001 and working with the Cloud Network of Mine since 2016. Together with me here is... My name is Diana Jordaan. I joined ING Hub Romania in 2017 while I was still at university, so I basically grew up in ING. Currently I'm an engineer in ING's CICD squad, building container deployment capabilities for DevOps applications. We're speaking here on behalf of ING, which is a bank with a large presence in some European countries, and a small presence elsewhere in this globe. It's a very special privilege to be on this KubeCon Amsterdam being the first Dutch person on stage, representing the first Dutch company on stage, as ING was founded in the Netherlands and is headquartered in Amsterdam. So on behalf of ING, welcome KubeCon! Welcome to Amsterdam! Welcome to the Netherlands, the low countries where people live under the sea level. Can I see some hands? How many of you think we are currently below sea level? Well, we have a mix of visitors and locals. I can reassure you, we are quite secure here. The right area is about four meters above sea level. However, if you move further away from the Amsterdam city center, those purple areas are more than five meters below sea level. I'm not going to ask who is staying in a hotel near Schiphol tonight. So yeah, should you be concerned? If you go by the Dutch folklore, you might have some valid reasons to be concerned. Because looking, basically neglecting your primary defenses, looking for holes, and then charging to the rescue is not a security best practice. However, it is daily reality for most of IT environments in this world today. And that's a very sad conclusion. How do we actually protect the Dutch against the rising water? And our visitors, of course. Well designed, well maintained infrastructure. So you'll be quite safe here during your stay. But that didn't happen by magic. The Dutch learned the hard way how to deal with a threat landscape, which is evolving. We had official reports in the 1930s. 1937, 1940, 1946, we were warned that our defenses were weak. And those making the decisions set different priorities. Until it was too late. One dreadful morning in 1953, the sea attacked and swarmed large parts of the Netherlands. And then we still had to spend all that effort to prevent the same disaster from ever happening again. That took us 40 years, 6 billion euros, not corrected for inflation, and about 1 billion euros mainly in maintenance. But the good message is that maintenance is guaranteed by law. So the Dutch learned how to protect themselves the hard way. But I can really recommend not trying the hard way if you can avoid it. At just before that point. And to help you out with that, we have some lessons from the past, which are still very applicable today. First one here is a quote not from Darwin, but a quote from an American professor called Maganssen, Leon C. Maganssen, who was a professor of management and marketing. And of course, I've liked the article, which is quote, come from lessons from Europe for American business. How applicable today. And of course, the quote is very well known. It's not the strongest of the species that survives, nor the most intelligent that survives. It's the one that is most adaptable to change. So the lesson we can learn from that today's cyber trap environment calls for it landscapes and hence the organizations they are supporting to adapt and adjust or else they will perish. But that lesson is indeed still to be understood in many IT organizations, which makes me wonder, how bad does it need to get for IT systems? If all these have proven not to be impactful enough to really start addressing our security issues? What to say about this slide? All these examples aren't even covering the damages done to those losing their privacy, reputation, wealth, or even worse. When will we as an IT industry start to take real ownership of the responsibility to secure the data entrusted to us by society? How sure are you your data organization isn't next in line? Would you like to spend the rest of your career looking for and plugging holes? And do you really think that will save you in the long run? Or would you rather make a difference start transforming now to address the fundamental issues? Diana will now share some concrete insights into common weaknesses you might not even be aware of. What has gone wrong with this privilege? This picture shows a typical application stack. You have the OS at the bottom, the application on top, and all these agents and endpoints in between. In theory, if we rely on the least privileged principle, all these layers should only have just enough permissions to perform their tasks. But did you think about the self-updating capabilities and what do they imply? In practice, anybody with the slightest motivation is apparently able to get elevated privileges. And please don't assume public cloud is any better. Could it be worse? Yes, multiply that by 1000 stacks. What do you do with all those credentials for all those systems? Do many organizations keep them identical resulting in APT highways? Imagine the waterworks electricity and postal services requesting you to change the cylinder in the door of your house to a generic key, shove it everybody else in your city. Would you accept that in real life? But I purchased zero trust solutions. I should be secure. Let's take a popular recent example, SolarWinds. They have this system called Orion, which is used by a lot of companies to manage IT resources. Hackers secretly broke into SolarWinds systems and inserted malicious code into their software. So when SolarWinds sent out their update to their clients, they also spread out the malicious code inserted by the hackers. This is an example which shows that nobody is in control of software lineage. In addition, people usually just trust the solutions they purchase, but don't think into account that those could be overprivileged. For example, if we go back to our SolarWinds example, the elevated root privileges used by the Orion components enable lateral movement and take over of systems. Therefore, relying on zero trust implementations does not compute if the fundamentals are shaky at best, which is not really a surprise. Wise men already highlighted the dangers of not addressing weaknesses 2,500 years ago. And that man is San Wu, a well-known military strategist and also the author of the book, The Art of War. Let's take this code, for example, the opportunity of defeating the enemies provided by the enemy himself. This navigate of wisdom can also be applied to the IT infrastructures we build and run. Imagine what would happen if you actually addressed our fundamental IT weaknesses. For example, from an APT's perspective, its victims provide the opportunities. But if you take care of those weaknesses, then the attackers cannot exploit those points anymore. Even with a limited budget, you can still tackle your most important blind spots. So the lesson here is, know your weaknesses and address them. And Thais will now share what the impact of shaky fundamentals is. The current state of affairs regretfully is that most good folks are living the movie Groundhog Day. Every day, they try to scan, patch, chase false positives and report on their activities. And whatever the outcome, the next day will be the same. Keeping ourselves busy is not solving the problem. Even worse, this is wearing down our staff. While this industry screams we have shortages, why would that be? Groundhog Day is quite the opposite of a staff retention strategy. Will bolting on more of this really help to solve our challenges? I do not believe so. I believe this industry needs a paradigm shift. We need to get away from bolting on security. Forget about this approach. We tried for decades and see where we are today with the average IT security posture. Adding even more detection and response won't save you in the long run. Bottom line, this tech sector is failing at cybersecurity. Global spending on it is $190 billion a year. And what does that buy us? Our aim should be secure by design. Fix the fundamental issues. I'm pretty sure the team building these did a thorough analysis or to be expected threats. I'm pretty sure these vehicles were very well tested before any VIP ever sat down in them. And I am pretty sure these vehicles will never be stand alone. They are fully integrated into a larger security system. Typically, you are playing for a draw. At best against our IT's adversaries. What you should aim for is playing to win. But how? Let's have a look at what the industry produced in recent years. Most of you, especially those of you who are the percentage which has attended KubeCon before, will recognize these logos. But for all the first timers, let's go through them. We have Kubernetes in its various distributions, which is available. You can do namespaces of service on top of that Kubernetes. We have infrastructure as code. We have policy as code. We have CICD. We have eventing. We have persistency, tablespaces, buckets, etc. We have observability. We have identity and access management. All of the above are available as a commodity in public cloud and with a bit of effort in private clouds. And of course, we look at the industry best practices, which have been around for quite some years, like separate production from non-production. CICD, test-driven development, software development lifecycle, network segmentation, and 12-fact application development. But I think we need to be very opinionated and specify internet use to really create results. So let's take another lesson. Does anybody recognize this gentleman? You might not even realize you heard about him before. War is the continuation of policy with different means. That's a fairly common quote. This gentleman lived during the Napoleonic era. He never saw a computer or experienced the internet. However, his teachings are still very applicable to cyber security. Let's start with the first one. A fast-moving theory must also take into account the human element. It must accord a place to courage, to boldness, even to rashness. Deep proverbial, thick fingers. Second, a fast-moving environment can evolve more quickly than a complex plan can be adapted to it. By the time you have adapted, the target has changed. So here we have two quotes supporting the idea of immutable short-living architectures. As those, by forcing a strict change process, will significantly decrease the human errors, whilst at the same time offer a high evolution suite of the landscape. What's our own attacker, which has detected vulnerabilities, will no longer find those on return. A long time ago, I attended aerospace engineering classes, and this quote hit a nerve apparently. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. In aerospace engineering, this is a D mantra if you want to construct something which can lift off the Earth's surface or even leave this Earth's atmosphere. So our lesson today is, security is achieved, not when there is nothing more to add, but when there is no credential left to take away, a.k.a. the true intended outcome of Lee's privilege. Zero privilege. And this is not nothing special, nothing new. Manufacturing industries are doing it today. No more natural persons on the production platform during production runs, resulting in consistent quality and reduction in injuries. If something needs to be adjusted, that is only possible via a strict process, but how to apply this to an IT platform. So let's combine everything we discussed so far. We end up with these two outcome-based principles to define zero privilege architectures. First principle, any change to the system is the result of a controlled process, meaning changes cannot be done by a single natural person, whether in or outside your organization. Second principle, any component of the system runs immutable yet ephemeral, meaning in case it no longer conforms to the desired state, it is killed and redeployed by the process as described in principle one. And a warning to all ego marketeers. Zero privilege is about secure ecosystem design. It's not about products. So how could this be implemented? We start with a CSCD pipeline that's the only entry for changes into the system. No more patching in whatever shape or form. Always redeploy. We have a hosting environment, in this case container hosting, which is immutable. And we have workloads, which are also immutable. Administrators define and trigger CSCD pipelines. Those pipelines deploy or redeploy platform and workloads. Which also means administrators no longer have access to either workload or platform. In an enterprise context, you want information on that platform. For various reasons. We no longer allow agents to be installed. Overprivileged agent, typically, to collect that information. Information gets pushed out. And anybody who wants that information can collect it from topics and endpoints and use that to populate the dashboards and alerts, which are important. Which gives our administrators a second task. They need to define and watch those dashboards and alerts. And the paradigm applies to everybody. Also security staff does not get access to the runtime platform or the hosted workload. If they need a response capability, that can be built, but that goes via the CSCD pipelines. Workloads are immutable. So you need data services to proceed your state. Technical state compliance monitoring and anomaly detection have become part of the hosting platform. It's no longer a separate product or separate component. Identity and access management becomes really simple. We are only left with view only accounts. In the handful of pay class accounts and we'll get back to that. Automated compliance, vulnerability scanning, automated testing, software asset management. All those interfaces connect to the CSCD pipeline. Since we guarantee immutability, that's good enough. And it also helps us to get rid of a lot of potential APT highways into the hosting environment. And I mentioned pay class. By definition, nobody knows what to test for. The scope will never be complete. Same applies for your dashboards. There will always be situations you didn't expect. So define those pay class accounts. You will need them. But what separates the men from the boys, so to speak, is what you do after you use that pay class account. You should redeploy from the pipeline the entire affected scope of the environment. Do not fix in production. And you need an organizational model and mindset automate everything I want to support this model. So this is a view which might appeal to architects, to engineers, to developers. But it won't convince all the stakeholders you need to convince. So for that Diana has some additional help. We first start with one more one clause of its code. The talent of the strategist is to identify the decisive point and to concentrate everything on it. Removing forces from secondary fronts and ignoring lesser objectives. Definitely a wise lesson for the decision makers amongst us. So let's translate that to today's context. Stop compensating. Stop bolting on security. Address your fundamental issues. Which brings us to the elevator page. Do you want to keep your organization alive in today's arbitrate landscape? If the answer is yes, then you should redirect investments to fix fundamental issues instead of spending on compensation. And how do you do that? By investing in refactoring applications. Investing in zero privilege infrastructure and automating everything in segmenting domains. Investing in your staff. And what do you achieve by doing all of that? You significantly reduce the risk of success for ransomware attacks. You stabilize the environment by a significant reduction of operational errors. You reduce the risk of bad press, fines, personal consequences due to data leakages. And as an additional benefit, you have been digitally transformed. To support another stakeholder viewpoint, we'll present today our last Samu lesson. The main point of his book is not about winning a fight, but how to be better prepared, how to avoid fighting. Just like we see here, the greatest victory is that which requires no battle. Please realize our typical adversaries also have policies and budgets to deal with. Imagine the discussions on the opposite side once they realize our defenses are so strong, their business case turns out to be negative. They'll just move on quietly to the next opportunity and hope their senior echelons won't ask any nasty questions about the time or budget already spent. So the lesson here is, get your defenses in such a shape, the enemy will search for easier prey, which prepares us for the last zero privilege which should resonate with yet another group of stakeholders, those in security and compliance. We won't explicitly go through all these aspects of this view due to the time reasons, but we'll highlight just two defenses which might make an adversary team twice before investing into targeting this ecosystem. One, adversaries can no longer gain control over privileged accounts, as those have vanished from the workload hosting. And two, anomaly detection rules and TSM definitions have become policy as code in the literal sense. Please feel free to approach us later for a walkthrough. That's nice and teary, but can it even be built? Of course. ING has been running its ING Immutable Container Hosting Platform version two since Q3 last year, and version one which was partly immutable since Q2 2018. ING has been running its one pipeline CHD environment since Q2 2019, supporting amongst others immutable container deployments. And to make it more concrete, I'm not trying to unlock my phone now, but on this phone runs the ING mobile app. That mobile app is serving millions of customers daily, helping them sort out their finances. Over 50% of the APIs supporting this app is hosted in this immutable landscape. Those are immutable workloads serving the endpoints. Our colleague Adnan is giving some insights this afternoon, 4.30, whole seven Room A, on what it is like to be deploying and running workloads in this ING private cloud ecosystem. And will even be open sourcing some of the components we built to construct this ecosystem. This Thursday, one o'clock at the ING booth at 7.05. So this was an intensive presentation, but we are happy if you remember three things. First, you are playing for a draw at best against your IT security adversaries. Second, an IT security paradigm shift is required if we as an IT industry want to be recognized by society as responsible stewards of their data. Because frankly, we're not doing that good a job today. Third, from a technology perspective, there are no more excuses to play to win, especially if those technology advances are combined into a zero privilege architecture. And we would like to ask you, which part of a zero privilege architecture implementation are you going to dive into? Kubernetes, names, pages of service, CICD, data persistence services, observability, 12 factor apps, automated testing, it doesn't matter where you start. It's not going to be a big bang migration anyway. Pick something and start. Please share this intent publicly on your social media now to make sure you do. Hashtag zero privilege. Before we continue, we would like to make our apologies towards you, our dearest security developers, engineers, product owners, product managers, architects, contributors, maintainers, and so on. We have been blessing your hard work in this presentation, but we do hope by now you understand why we felt the need to do so. We do know and appreciate the large majority of you is doing this utmost every day to make this world a safe place, and we apologize for ignoring that fact until now. If you agree with us that a paradigm shift is needed to win against our adversaries and would like to improve your products, to give society the security levels it should be entitled to, please do not hesitate to reach out to us. We'll try to help out in any way we can. These are some of the questions we commonly get. We did not expect to be in such a large venue. So for practical reasons, we propose to approach us in the hallway track or at the ING booth or via Slack for your specific questions. And we'll go through these prepared questions now. So the first question we often get, my organization is not a bank. We cannot afford to run these kind of infrastructures. Well, perhaps that is true, but in that case, the reverse question becomes just as relevant. Can you afford to host and adequately protect the data which is currently stored in your IT landscape? If the answer to that question is negative, please do society a service and delete data which isn't really needed as soon as possible. And if you're selling services in the European Union, that also might save your organization from a hefty GDPR fine. Second question we commonly get, doesn't this collide with the current views implementations of established entities in the security and compliance industry? Most certainly, by design, we need a paradigm shift. This industry has come a long way, but the threat landscape has evolved to such a point we have to face the reality that bolting on solutions is insufficient to fulfill the data protection obligations we have to society. So entities in this industry need to evolve or else they are at risk of getting extinct. Some well intended advice, become part of the redesign of systems, interact in early stages with your potential customers, forget about the one-size-fits-all solution, open up and allow others to feed in, e.g. using topics or endpoints, and then there's still an option to play a role in providing enterprise-wide security observability and reach out to the CICD providers and SAC DevOps teams. You can still interface with pipelines for a responsibility. My workloads won't feed this architecture, and that could be very true. Workloads will need to adapt in order to feed its architecture. There's no way around that. But the benefits should outweigh the efforts. If they don't, stay where you are and focus on other medications or have a second look if your risk assessment is still accurate. And also we'd like to make a note on application access. It is still possible to connect with any privileged application hosted in such a zero-privileged runtime environment, although it would be prudent to apply similar principles for the application itself. This runtime hosting architecture description ends at the boundary of the hosted namespace. The boundary between hosting infrastructure and application might even turn out to be a natural boundary between zero-privileged and properly implemented zero-trust paradigms. And if you like the session, we prepared for you in this Cloud Native Security Talk, then, and you want to know more of these words available with them translated into Cloud Native context, then we can highly recommend this book to you written by Pini, Jamie and Michelle and best of all, it is available to download for free as a new book via this QR code. One more thing. Are we the only one putting the finger on the source spot? Which of you recognizes this lady? I'll give you a hint. She was cybersecurity person of the year 2021 and her resume is impressive. She gave a national address February 27th this year. Unsafe at any CPU speed. The design dangers of technology and what we can do about it. In which she stated, we need to make a fundamental shift if we want to do better. And we must do better. And she had three important principles to share. Take ownership of the security outcome. Take accountability for your products. Focus on building safe products which are secure by design and secure by default. Doesn't that sound familiar by now? And one puts should certainly pay attention as she holds the office of CISA director. Her name is Jen Easterly. And I have another hot off the press prize for you. That was even two reasons for my slides. So this is not in the slides on sketch yet. Last Thursday, this was a press release from CISA together with FBI, NSA, and the cybersecurity authorities of Australia, Canada, United Kingdom, Germany, the Netherlands, and New Zealand. They published joint guidance which urges software manufacturers to take urgent steps necessary to ship products that are secure by design and default. I would summarize that as imposing an IT security paradigm shift. And with that, over to Diana. Thank you very much for your attention. We hope that we have met your expectations and succeeded in kicking off this KubeCon security track. And I would like to add to that, enjoy KubeCon. Enjoy Amsterdam. Make a difference. Hashtag zero privilege. Thank you all for being a great audience. See you later.