To stay competitive during the times of digital transformation, when business models and technology landscapes change daily, enterprises must reinvent many of their business processes to achieve new levels of agility and flexibility, and nowhere else this is more evident than in software development. As the demand for faster design, development and delivery of software is growing, organizations are adopting the DevOps methodology that fundamentally changes the ways software is produced.
With a strong focus on practices like continuous delivery, infrastructure as code and test automation, DevOps can do wonders for development productivity. Unfortunately, quite often this is done at the expense of governance and security, which many developers see more as obstacles that prevent them from achieving the desired level of agility. Adding the newest disruptive technologies like containers or microservices to the mix only makes the matters worse by opening an entire range of new possible attack vectors.
In this session, we’ll talk about the organizational and technological measures needed to close the rift between DevOps agility and strong IT security as well as have a look at some of the today’s most popular DevOps trends and discuss their biggest security challenges.
On this slide. I just listed a few problems. Everyone is basically dealing on a daily basis. Everyone, is it? And, and or the consequences of those problems that, yeah, basically we are missing visibility into what's going on in our networks and infrastructures. We are severely lacking. The people needed to address those problems. And obviously we are severely lacking the money for that. In the end, we have the it departments, which are frustrated, overworked and universally hated by everyone else in the company. So what has been done in the recent years to, to change the table? The tables turn the tables. Obviously since our, the business is now, now increasingly digitalized or agile, flexible, they have to adapt to new challenges on a daily basis. They have to embrace new technologies or here are the key expectations. Every business has from the it departments. They need visibility and not just in the it focus, not just which bites are flowing across the networks, but really what's going on.
What are the new assets? What are the new challenges? What are the new problems and what are the numbers, which could be reported to the upper level, especially in regards to regards to compliance the, it has to provide the utmost agility, which can only be, which can only work out if our, it works hand in hand and collaborates with the business units all the time. And of course it's all about security because we are talking about security today and this security are policies. It has to be policy when it has to be strongly focused on risk management, because this is how businesses think about security. And it has to be smart, automated to ensure that every problem can be addressed in real time. So in a sense, modern it security can be summarized to these three terms. It has to be driven by business requirements. It has to be integral part of our business process. It has to involve every party within the company and not just within the it department or development, development and operations, but literally everyone. And it has to be intelligent.
Unfortunately, for many people in and out of it, cybersecurity still remains some kind of product, a thing, which you buy once put on a shelf and it works on its own. I usually call it cybersecurity cargo cart, or after that kind of known phenomenon absorbed in the Pacific islands during the world war II, where the natives were building airports out of straw and, and wood hoping that it'll attract the magic planes, bringing the cargo, the goods for them. And in a sense, we are still absorb this culture in the modern enterprises. And of course it has to be addressed. It has to be changed. And security culture is something which does not just pop up. It has to be worked out from both ends on one hand it's, it's literally about everyone's awareness. Everyone has to be a part of the culture. On the other hand, it has to be leadership driven and it has to be governed and controlled appropriately utilize on things which were already discussed are in the earlier presentations today or on clear policies on very well trained incident response procedures, training for employees and kind of the real world training, not just e-learning which way you click some check boxes and you are done.
And, and, and it has to be a continuous process. It has to involve all aspects of security, starting from physical things. Don't leave your USB around and don't pick up someone else's wants, or you have to be extremely agile against and fraud. You have to be constantly updated on the recent, the most recent regulations regarding privacy and data protection. And for developers, it basically boils down to the thing which is called Def SecOps in which I will address a little bit later, but more importantly, it, it has to be engaging. Otherwise it'll never work. So what is dev SecOps? Obviously it's like DevOps plus security, or whereas when we are talking about DevOps, we are usually talking about automating the whole process of software delivery from coding, to being, building, testing, integration, deployment, and tailor operations, or dev add another aspect of that. Or so DevOps is seen as infrastructure as code where everything is configured and versioned, and every change is direct and everything is automated with regards to what's called continuous integration process.
Defs add security is called where exactly the same principles have to be applied to security. We are no longer talking about security tools or as addons or no longer. It's not about firewalls or antivirus. It's really about making our security in the same integral part of the whole process. And of course, it's relies on collaboration while talking about devs. One cannot really avoid talking about another acronym, which is data ops for many kind of desktops is limited to the actual development, the coding, whereas in the end, the whole reason that coding happens is about data is about collecting data, sharing data, modifying data, and then securing the data and data ops, or it kind of introduces the same approach towards data management. Originally it was created by the guys from the data analytics business, but it can very well be applied. I mean the same principles applied to development and security as well.
Basically, it's all about automating access to data, regardless whether it's about a data Analyst who needs to run a, some business intelligence research on a customer data or a developer who needs to, to extend a business application or testers, or just some sharing of database third parties, or as soon as we have GDPR and other regulations, which apply to the kind of data, it, they introduce a massive friction, or they say that it may take up to one week for developers to, to get a, the fully sanctioned and cleared and authorized copy over production database in a highly secure environment. And of course, just like we have shadow it, we will have shadow data ops, but able just steal or whatever the regulations. And there are some interesting technical development in this area happening now. And one I would like to mention is data virtualization, which relies heavily on automating the whole data delivery and data integration process with very simple idea, that instead of getting a copy of a database, you are supposed to actually get access to the original, which isn't original after all.
Basically you get a virtual snapshot of the data, which is on one hand live and may even be updated when the original data is updated, but it's actually automatically verified, cleaned, anonymized, whatever you name it with all the security and compliance policy applied, delivered straight into the hands of the data, consumer automated safe. Again, I'm not going to dive into technical details for the reason of time, and let's kind of jump directly to the title of the presentation, but yes, APIs containers, Microsoft. I really don't think I have to explain the meaning of each of these three acronyms, but when I was given this title, other kind of recommendation for this presentation, like APIs and containers equals to equals microservices, basically. So what's there to discuss, that's the whole point that are every time you add something up, you also add the risks and threats and other challenges.
Now, again, we will start with APIs or APIs are the API economy has been there for a decade probably, or for some companies, APIs have become not just the way to automate their processes or optimize some data exchange with third parties. It really became their core competence and the, the main source of income, be it, some weather prediction service, or even Facebook and Google and Uber and any other companies which basically rely on APIs to do their daily business. The problem are in that are APIs in especially recipes are great for developers, especially for lazy developers. They're simple. They are at hoc, mostly still for, for many use cases though. Nobody even thinks about the whole security and protection of those APIs are five years ago. I started kind of tracking this area and about two and a half years ago, we have published a, a leadership compass.
We called a multi vendor report on API management and security solutions. And there was really one company in the whole world, which called themselves an API security vendor. Now I am working on a update with a document and I already have found five, which is nearly not enough still, but still a great positive improvement. And I have even met one company who claims to be API security analytics company. So it's, I mean, machine learning thrown into it though on this slide, I just summarized all the aspects of threats and challenges you have to think about when publishing an API. And definitely we are not going to dive deep into the, some of those will be cared by other speakers in this presentation. But basically my message here is that API security is pretty difficult and nobody is thinking about it and at best, or they would start thinking about it after the API is compromised and again, or security by design principle applies to APIs just as well as every other software development area. So this is just again, without diving into details, much an example of the typical approach to API security. Now, basically you have your APIs somewhere with backend or microservice or third party or interface, and you bolt another security layer on top.
What, when one typically thinks about an API gateway, there is a lot of this products on the market. It's all about billing and monetizing and quarters and at best or about access controls through API keys. As I mentioned, a proper security gateway has to implement all of those. It has to protect from external threats, internal threats, and again, our access control will be covered in the next presentation. Another popular buzzwords are containers. Containers are awesome because they are portable. They are efficient. And finally, they are standardized enough for us. I'm still saying us because I used to be a developer for years, myself, for us developers, to be able to write once and run everywhere. Remember Java was using this slogan. Something like 20 years ago or 20 years later, we have containers, which are almost there. So no wonder that containers dock is such a rage for everyone, for every developer here, there are companies who are basically using those terms as a marketing buzzwords, just like 10 years ago, a company would say, we are now cloud native because reasons because it's awesome. Some companies would say we are now container native. So what apparently for some marketing people is world alone. Sounds it's awesome.
Again, when one is talking about containers, no, we have a lot of offers from companies around the world and small cloud native for on-prem or hybrid offering. You fully managed, fully automated, totally intelligent. And of course, absolutely high performance contained infrastructures, but nobody's talking about security. And on this slide, I have listed again, just a short or selection of things. One have to deal with when secure they contain infrastructures. So obviously containers run on a physical server somewhere. So that server has to be protected. Containers are built from operating system images like Linux. Those images has to be protected, have to be protected. They have to be hard on secured validated that have not been compromised or during some stage of the development and integration process. And of course the actual applications which are running on those containers have to be secured the traditional way.
So basically on the left side of this slide, you have the same problems we have in the traditional application development of operations, but they apply to contain infrastructures just as well on the right side I've list, a few more problems, which are more or less relevant for containers on top of the common ones. So obviously you have to protect all the publicly facing interfaces. We are coming back to the whole API security scope. Remember that huge diagram on the previous slide are, we have to remember that containers are run in our much less isolated from each other and also machines. So there is this whole container breakout problem, which has to be addressed specifically where one container can be maliciously modifying. For example, the, the image of the other one, we have resource hogging, or again, it can be a typical problem or not being able to cope with the load, or it can be a malicious application just eating up all the available resources.
It still has to be monitored or for all the security and compliance issues like every other infrastructure and, or last, but at least this whole part of the C CDs or the continuous integration and development chain, which has now expanded towards integrating containers, has to be secured as well. And on the right side, I've just included a screenshot from a recent article. I law, the Russian airlines, they are probably one of the biggest companies in Russia, kind of heavily invested in containers. The whole public facing interfaces are fully contained rise and ISU remotely. If you believe that claims they are highly secured and everything was done according to the, the proper best practices, but unfortunately they have forgot to secure the development copies of their container images. And as soon as some hacker managed to compromise the Docker registry, they immediately have access to the whole source codes, interface, specifications, who knows maybe even data. Unfortunately, there is no GDPR in Russia yet, so we don't know how many customers were moved, but you can never exclude that possibility.
Excuse me. So what can be done or what are some high level recommendations regarding container security? Again, just like every other aspect of informal security. There is no tool which can be called or tone key out of the box container security tool. It has to be a part of alert, existing security infrastructure, and like every other aspect of cybersecurity, it has to begin with full visibility. You have, you have to know what you are supposed to protect on every layer of this whole container stack all the way from the all the way down from the bare metal up to the actual application has to be hardened separately. And you'll probably need experts, separate experts for each of those layers. And of course all the other security technologies, which are being discussed nowadays, and probably even by some speak other speakers or during this conference, micro segmentation, risk privilege enforcement security gateways already mentioned real time security intelligence in other hot topic. That's is where all this AI and machine learning is hiding. And of course last but not least, you have to remember that about the human factor. We are the biggest link. The developers are lazy and negligent, and unless you enforce your security through and through, they will always find a way to compromise your application.
And here we are highly coming to microservices. So again, just as an illustration, microservices are basically, or at least now when you are looking in the marketing literature, it basically boils down to containers. Plus APIs, someone is maybe mentioning serverless services like Amazon Lambda, but for most it's just containers APIs. So when you are thinking about microservices security, again, it boils down to combining API security, which is pretty then complicated. As I mentioned with container security, which is again, basically covering all the aspects of traditional security with a twist on top. And you end up with a seriously complicated match of additional services, which have to be integrated as deeply as possible into your existing application infrastructure. So on this slide, each kind of blue part, maybe an API micro gateway or an additional like security microservice, or maybe microservice antivirus, or microservice firewall, basically you name it or, and of course the market response or annually, everyone wants to sell you micro firewalls and micro web application firewalls and micro you name it. But basically it boils down to, again, boils down to increasing complexity or further complications of the need to integrate with different platforms, which have different management interfaces are again, access management, identity Federation is a huge topic on its own. I am not even going to dive into that direction myself.
And again, it's all about, again, it's all about business aspects. You need to have governance. You need to have a strong audit trail. You need to think about all those think as well. So on this slide, basically, I just are thrown together a number of boxes. What are the key areas for securing microservices? And none of it is actually any, anything specific to microservices only it's all the traditional aspects of information security we have to deal starting from the low level infrastructure, all the way to our governance and compliance, and yet probably each box with its own twist in an additional level of complexity. And this is it basically. So we had this development from traditional it, which had no idea about security at all. Then we came to DevOps, which had a starting thinking about automation and automation as a one way to improve security. The next step is obviously diffs, where we are heading now, where security is going to become the integral part of this development of operation process. And somewhere in the future, nobody knows what kind of crazy parts add to the acronym. I just thrown in the best defe ops. I really hope someone else comes up with a better name for that. And basically that's it for my presentation today. Thanks a lot. And we do have a couple of minutes left for any questions.
How can we help you